Путеводитель по RFC

Более подробную информацию по протоколам семейства TCP/IP и способам организации сетей internet можно найти в RFC - документах, распространяемых DDN Network Information Center. Полный каталог RFC, а также сами документы можно получить по электронной почте, обратившись по адресу service@nic.ddn.mil. Поле "Subject:" в вашем запросе должно содержать название желаемого документа. Например, для получения RFC 822 вы должны указать

    Subject: RFC 822

Для получения дополнительной информации пошлите письмо, указав

    Subject: HELP

Каталог RFC содержит полный список документов, упорядоченный в обратном хронологическом порядке. Его можно получить, послав запрос

    Subject: RFC INDEX

Тематический каталог RFC

Административные вопросы
Administrative

RFC о выделенных номерах
Assigned Numbers RFCs

1117, 1062, 1020, 1010, 997, 990, 960, 943, 923, 900, 870, 820, 790, 776, 770, 762, 758, 755, 750, 739, 717, 604, 503, 433, 349, 322, 317, 204, 179, 175, 167

Официальные стандарты IAB и другие списки протоколов
Official IAB Standards and Other Lists of Protocols

1130, 1100, 1083, 1011, 991, 961, 944, 924, 901, 880, 840, 694, 661, 617, 582, 580, 552

774 - Internet Protocol Handbook Table of Contents

Отчеты о заседаниях рабочих групп
Meeting Notes and Minutes

1152 - Workshop report: Internet research steering group workshop on very-high-speed networks
1077 - Critical issues in high bandwidth networking
1019 - Report of the Workshop on Environments for Computational Mathematics
1017 - Network requirements for scientific research: Internet task force on scientific computing
898 - Gateway Special Interest Group Meeting Notes
808, 805, 469 - Computer Mail Meeting Notes
910, 807 - Multimedia Mail Meeting Notes
585 - ARPANET Users Interest Working Group Meeting
549, 396, 282, 253 - Graphics Meeting Notes
371 - International Computer Communications Conference
327 - Data and File Transfer Workshop Notes
316 - Data Management Working Group Meeting Report
164, 131, 116, 108, 101, 082, 077, 066, 063, 037, 102 - Network Working Group Meeting

Oбъявления
Meeting Announcements and Group Overviews

1120 - Internet Activities Board
828 - Data Communications: IFIP's International "Network" of Experts
631 - Call for Papers: International Meeting on Minicomputers and Data Communication
584 - Charter for ARPANET Users Interest Working Group
537 - Announcement of NGG Meeting
526 - Technical Meeting - Digital Image Processing Software Systems
504 - Workshop Announcement
483 - Cancellation of the Resource Notebook Framework Meeting
474, 314, 246, 232, 134 - Network Graphics Working Group
471 - Announcement of a (Tentative) Workshop on Multi-Site Executive Programs
461 - Telnet Meeting Announcement
457 - TIPUG
456 - Memorandum
454 - File Transfer Protocol Meeting Announcement
453 - Meeting Announcement to Discuss a Network Mail System
374 - IMP System Announcement
359 - The Status of the Release of the New IMP System (2600)
343, 331 - IMP System Change Notification
324 - RJE Protocol Meeting
323 - Formation of Network Measurement Group (NMG)
320 - Workshop on Hard Copy Line Graphics
309 - Data and File Transfer Workshop Announcement
299 - Information Management System
295 - Report of the Protocol Workshop
291, 188, 173 - Data Management Meetings
245, 234, 207, 188, 173, 140, 116, 099, 087, 085, 075, 043, 035 - Network Working Group Meetings
222 - System Programmer's Workshop
212 - NWG Meeting on Network Usage
157 - Invitation to the Second Symposium on Problems in the Optimization of Data Communication Systems
149 - The Best Laid Plans...
147 - The Definition of a Socket
111 - Pressure from the Chairman
048 - A Possible Protocol Plateau
046 - ARPA Network Protocol Notes

Списки распространения информации
Distribution List

402, 363, 329, 303, 300, 211, 168, 155 - ARPA Network Mailing Lists
069 - Distribution List Change for MIT
052 - Updated Distribution List

Официальные вопросы
Policies

1124 - Policy issues in interconnecting networks
1087 - Ethics and the Internet
1052 - IAB recommendations for the development of Internet network management standards
1039 - DoD statement on Open System Interconnection protocols
980 - Protocol Document Order Form
952, 810, 608 - Host Table Specification
945 - A DoD Statement on the NRC Report
902 - ARPA-Internet Protocol Policy
849 - Suggestions for Improved Host Table Distribution
678 - Document Formats
602 - The Stockings Were Hung by the Chimney With Care
115 - Some Network Information Center Policies on Handling Documents
053 - An Official Protocol Mechanism

Документы о RFC
Request for Comments Administrative

1150 - F.Y.I. on F.Y.I.: Introduction to the F.Y.I. notes
1111 - Request for comments on Request for Comments: Introductions to RFC authors
1000 - Request For Comments reference guide
999, 899, 800, 699 - Requests for Comments Summary
825 - Request for Comments on Requests for Comments
629 - Scenario for Using the Network Journal
628 - Status of RFC Numbers and a Note on Pre-assigned Journal Numbers
598, 200, 170, 160, 100, 084 - RFC Index

Библиография
Bibliographies

1012 - Bibliography of Request For Comments 1 through 999
829 - Packet Satellite Technology Reference Sources
290 - Computer Network and Data Sharing: A Bibliography
243 - Network and Data Sharing Bibliography

Разное
Other

637 - Change of Network Address for SU-DSL
634 - Change in Network Address for Haskins Lab
616 - Latest Network Maps
609 - Statement of Upcoming Move of NIC/NLS Service
590 - MULTICS Address Change
588 - London Node is Now Up
551 - NYU, ANL, and LBL Joining the Net
544 - Locating On-Line Documentation at SRI-ARC
543 - Network Journal Submission and Delivery
518 - ARPANET Accounts
511 - Enterprise Phone Service to NIC From ARPANET Sites
510 - Request for Network Mailbox Addresses
432 - Network Logical Map 423, 389 - UCLA Campus Computing Network Liaison Staff for APRA Network
421 - A Software Consulting Service for Network Users
419 - MIT-DMS on Vacation
416 - The ARC System will be Unavailable for Use During Thanksgiving Week
405 - Correction to RFC 404
404 - Host Address Changes Involving Rand and ISI
403 - Desirability of a Network 1108 Service
386 - Letter to TIP Users - 2
384 - Official Site IDENTS for Organizations in the ARPA Networks
381 - Three Aids to Improved Network Operation
356 - ARPA Network Control Center
334 - Network Use on May 8
305 - Unknown Host Numbers
301 - BBN IMP No. 5 and NCC Schedule for March 4, 1972
276 - NIC Course
249 - Coordination of Equipment and Supplies Purchase
223 - Network Information Center Schedule for Network Users
185 - NIC Distribution of Manuals and Handbooks
154 - Exposition Style
136 - Host Accounting and Administrative Procedures
118 - Information Required for Each Service Available to the Network
095 - Distribution of NWG/RFC's Through the NIC
016 - MIT

Основные требования
Requirements Documents And Major Protocol Revisions

Требования к узлам
Host requirements

1127 - Perspective on the Host Requirements RFCs
1123 - Requirements for Internet hosts - application and support
1122 - Requirements for Internet hosts - communication layers

Требования к шлюзам
Gateway requirements

1009 - Requirements for Internet gateways

Уровень интерфейса с сетью
Network Interface Level

Отображение адресов (ARP, RARP)
Address Binding

1027 - Using ARP to implement transparent subnet gateways

Межсетевой протокол IP в различных сетях
Internet Protocol over another network

1149 - Standard for the transmission of IP datagrams on avian carriers
1103 - Proposed standard for the transmission of IP datagrams over FDDI Networks
1088 - Standard for the transmission of IP datagrams over NetBIOS networks
1055 - Nonstandard for transmission of IP datagrams over serial lines: SLIP
1051 - Standard for the transmission of IP datagrams and ARP packets over ARCNET networks
1044 - Internet Protocol on Network System's HYPERchannel: Protocol specification
1042 - Standard for the transmission of IP datagrams over IEEE 802 networks
948 - Two Methods for the Transmission of IP Datagrams Over IEEE 802.3 Networks
907 - Host Access Protocol
903 - A Reverse Address Resolution Protocol
895 - A Standard for the Transmission of IP Datagrams over Experimental Ethernet Networks
894 - A Standard for the Transmission of IP Datagrams over Ethernet Networks
893 - Trailer Encapsulations
891 - Internet Protocol on DC Networks
877 - A Standard for the Transmission of IP Datagrams Over Public Data Networks
826 - Address Resolution Protocol
796 - Address Mappings
795 - Service Mappings

Межсетевой уровень
Internet Level

Межсетевой протокол IP
Internet Protocol

1154 - Encoding header field for internet messages
1141 - Incremental updating of the Internet checksum
1071 - Computing the Internet checksum
1063 - IP MTU discovery options
1025 - TCP and IP bake off
815 - IP Datagram Reassembly Algorithms
791, 760 - Internet Protocol (IP)
781 - A Specification of the Internet Protocol IP Timestamp Option

Межсетевой протокол управляющих сообщений ICMP
Internet Control Message Protocol

1018 - Some comments on SQuID
1016 - Something a host could do with source quench: The Source Quench Introduced Delay (SQuID)
792, 777 - Internet Control Message Protocol (ICMP)

Межсетевой протокол групповых передач IGMP
Internet Group Multicast Protocol

1112, 1054 - Host extentions for IP multicasting

Маршрутизация и шлюзовые протоколы GGP, RIP, OSPF
Routing and Gateway Protocols

1136 - Administrative Domains and Routing Domains: A model for routing in the Internet
1133 - Routing between the NSFNET and the DDN
1131 - OSPF specification
1126 - Goals and functional requirements for inter-autonomous system routing
1125 - Policy requirements for inter Administrative Domain routing
1105 - Border Gateway Protocol (BGP)
1104 - Models of policy based routing
1102 - Policy routing in Internet protocols
1093 - NSFNET routing architecture
1092 - EGP and policy based routing in the new NSFNET backbone
1075 - Distance Vector Multicast Routing Protocol
1074 - NSFNET backbone SPF based Interior Gateway Protocol
1058 - Routing Information Protocol
1046 - Queuing algorithm to provide type-of-service for IP links
985 - Requirements for Internet Gateways
975 - Autonomous Confederations
970 - On Packet Switches With Infinite Storage
911 - EGP Gateway under Berkeley Unix
904, 890, 888, 827 - Exterior Gateway Protocol
875 - Gateways, Architectures, and Heffalumps
823 - Gateway Gateway Protocol

Разное
Other

986 - Working Draft - Guidelines for the Use of Internet-IP Addressing in the ISO Connectionless-Mode Network
981 - An Experimental Multiple-Path Routing Algorithm
963 - Some Problems with the Specification of the Military Standard Internet Protocol
950 - Internet Standard Subnetting Procedure
947 - Multi-Network Broadcasting Within the Internet
940, 917, 925, 932, 936, 922 - Internet Subnets Protocol
925, 917, 826 - Multi-LAN Address Resolution Protocol
919, 922 - Broadcasting Internet Datagrams
891 - DCN Local-Network Protocols
871 - A Perspective on the ARPANET Reference Model
831 - Backup Access to the European Side of SATNET
817 - Modularity and Efficiency in Protocol Implementation
816 - Fault Isolation and Recovery
814 - Name, Addresses, Ports, and Routes
796 - Address Mapping
795 - Service Mappings
730 - Extensible Field Addressing

Транспортный уровень
Transport Level

Протокол пользовательских датаграмм UDP
User Datagram Protocol

768 - User Datagram Protocol

Протокол управления передачей TCP
Transmission Control Protocol

1146, 1145 - TCP alternate checksum options
1144 - Compressing TCP/IP headers for low-speed serial links
1110 - Problem with the TCP big window option
1106 - TCP big window and NAK options
1078 - TCP port service Multiplexer (TCPMUX)
1072 - TCP extensions for long-delay paths
983 - ISO Transport Services on Top of the TCP
964 - Some Problems with the Specification of the Military Standard Transmission Control Protocol
896 - Congestion Control in IP/TCP Internetworks
889 - Internet Delay Experiments
879 - The TCP Maximum Segment Size and Related Topics
872 - TCP-ON-A-LAN
817 - Modularity and Efficiency in Protocol Implementation
816 - Fault Isolation and Recovery
814 - Name, Addresses, Ports, and Routes
794 - Pre-Emption
793, 761, 675 - Transmission Control Protocol
721 - Out of Band Control Signals in a Host to Host Protocol
700 - A Protocol Experiment

Протоколы для двухточечных каналов
Point-To-Point Protocols

1134 - Point-to-Point Protocol: A proposal for multi-protocol transmission of datagrams over Point-to-Point links
1055 - Nonstandard for transmission of IP datagrams over serial lines: SLIP

Протоколы надежной доставки датаграмм RDP, VMTP
Reliable Datagram Protocols

1151 - Version 2 of the Reliable Data Protocol (RDP)
1045 - VMTP: Versatile Message Transaction Protocol: Protocol specification

Транзакции и распределенные операционные системы
Transaction Protocols and Distributed Operating Systems

955 - Towards a Transport Service for Transaction Processing Applications
938 - Internet Reliable Transaction Protocol Functional and Interface Specification
908 - Reliable Data Protocol
722 - Thoughts on Interactions in Distributed Services
713 - MSDTP -- Message Services Data Transmission Protocol
712 - A Distributed Capability Computing System DCCS
708 - Elements of a Distributed Programming System
707 - A High-Level Framework for Network-Based Resource Sharing
684 - A Commentary on Procedure Calling as A Network Protocol
677 - The Maintenance of Duplicate Databases
674 - Procedure Call Documents--Version 2
672 - A Multi-Site Data Collection Facility
671 - A Note on Reconnection Protocol
645 - Network Standard Data Specification Syntax
615 - Proposed Network Standard Data Pathname Syntax
610 - Further Datalanguage Design Concepts
592 - Some Thoughts on System Design to Facilitate Resource Sharing
578 - Using MIT-MATHLAB MACSYMA From MIT-DMS Muddle - An Experiment in Automated Resource Sharing
515 - Specifications for Datalanguage, Version 0/9
500 - The Integration of Data Management Systems on a Computer Network
441 - Inter-Entity Communication - An Experiment
437 - Data Reconfiguration Service at UCSB
203 - Achieving Reliable Communication
076 - Connection-by-Name: User-Oriented Protocol
062 - A System for Interprocess Communication in a Resource Sharing Computer Network
061 - A Note on Interprocess Communication in a Resource Sharing Computer Network
051 - Proposal for a Network Interchange Language
031 - Binary Message Forms in Computer Networks
005 - DEL
001 - Host Software

Разное
Other

998, 969 - NETBLT: A Bulk Data Transfer Protocol
988 - Host Extensions for IP Multicasting
979 - PSN End-to-End Functional Specification
966 - A Multicast Extension to the Internet Protocol
869 - Host Monitoring Protocol
741 - Specifications for the Network Voice Protocol NVP
643 - Cross Net Debugger
162 - NETBUGGER3

Прикладной уровень
Application Level

Протокол сетевого терминала TELNET
Telnet Protocol

854, 764 - Telnet Protocol Specification
818 - The Remote User Telnet Service
801 - NCP/TCP Transition Plan
782 - A Virtual Terminal Management Model
764 - Telnet Protocol Specification
728 - A Minor Pitfall in the Telnet Protocol
688 - Tentative Schedule for the New Telnet Implementation for the TIP
681 - Network Unix
600 - Interfacing an Illinois Plasma Terminal to the ARPANET
596 - Second Thoughts on Telnet Go-Ahead
595 - Some Thoughts in Defense of the Telnet Go-Ahead
593 - Telnet and FTP Implementation Schedule Change
576 - Proposal for Modifying Linking
570 - Experimental Input Mapping Between NVT ASCII and UCSB Online System
562 - Modifications to the Telnet Specification
559 - Comments on the New Telnet Protocol and Its Implementation
529 - A Note on Protocol Synch Sequences
513 - Comments on the New Telnet Specifications
495 - Telnet Protocol Specification
466 - Telnet Logger/Server for Host LL-67
461 - Telnet Meeting Announcement
452 - Telnet Command at Host LL
435 - Telnet Issues
426 - Reconnection Protocol
393 - Comments on Telnet Protocol Changes
377 - Using TSO Via ARPA Network Virtual Terminal
357 - An Echoing Strategy for Satellite Links
355, 346 - Satellite Considerations
340 - Proposed Telnet Changes
339 - MLTNET - A "Multi-Telnet" Subsystem for TENEX
328 - Suggested Telnet Protocol Changes
318 - Ad Hoc Telnet Protocol
216 - Telnet Access to UCSB's On-Line System
215 - NCP, ICP, and Telnet: The Terminal IMP Implementation
206 - A User Telnet Description of an Initial Implementation
205 - NETCRT - A Character Display Protocol
190 - DEC PDP-10 - IMLAC Communication System
158 - Proposed Telnet Protocol
139 - Discussion of Telnet Protocol
137 - Telnet Protocol - A Proposed Document
135, 110 - Conventions for Using an IBM 2741 Terminal as a User Console for Access to Network Server Hosts
103 - Implementation of Interrupt Keys
097 - A First Cut at a Proposed Telnet Protocol
091 - A Proposed User-User Protocol
015 - Network Subsystem for Time Sharing Hosts

Опции Telnet
Telnet Options

1143 - Q method of implementing Telnet option negotiation
1116 - Telnet Linemode option
1097 - Telnet subliminal-message option
1096 - Telnet X display location option
1091 - Telnet terminal-type option
1080 - Telnet remote flow control option
1079 - Telnet terminal speed option
1073 - Telnet window size option
1053 - Telnet X.3 PAD option
1043 - Telnet Data Entry Terminal option: DODIIS implementation
1041 - Telnet 3270 regime option
946 - Telnet Terminal Location Number Option
933 - Output Marking Telnet Option
930 - Telnet Terminal Type Option
927 - TACACS User Identification Telnet Option
885 - Telnet End of Record Option
884 - Telnet Terminal Type Option
861 - Telnet Extended Options - List Option
860 - Telnet Timing Mark Option
859 - Telnet Status Option
858 - Telnet Suppress Go Ahead Option
857 - Telnet Echo Option
856 - Telnet Binary Transmission
855 - Telnet Option Specifications
854 - Telnet Protocol Specifications
779 - Telnet Send-Location Option
749 - Telnet SUPDUP-OUTPUT Option
748 - Telnet Randomly-Lose Option
736 - Telnet SUPDUP Option
735 - Revised Telnet Byte Macro Option
734 - SUPDUP Protocol
747 - Recent Extensions to the SUPDUP Protocol
746 - The SUPDUP Graphics Extension
732 - Telnet Data Entry Terminal Option
731 - Telnet Data Entry Terminal Option
729 - Telnet Byte Macro Option
727 - Telnet Logout Option
726 - Remote Controlled Transmission and Echoing Telnet Option
719 - Discussion on RCTE
718 - Comments on RCTE from the Tenex Implementation Experience
703, 702, 701 - Survey of New-Protocol Telnet Servers
698 - Telnet Extended ASCII Option
679 - February, 1975, Survey of New-Protocol Telnet Servers
669 - November 1974, Survey of New-Protocol Telnet Servers
659 - Announcing Additional Telnet Options
658 - Telnet Output Line Feed Disposition
657 - Telnet Output Vertical Tab Disposition Option
656 - Telnet Output Vertical Tab Stops Option
655 - Telnet Output Form Feed Disposition Option
654 - Telnet Output Horizontal Tab Disposition Option
653 - Telnet Output Horizontal Tab Stops Option
652 - Telnet Output Carriage Return Disposition Option
651 - Revised Telnet Status Option
587 - Announcing New Telnet Options
581 - Corrections to RFC 560 - Remote Controlled Transmission and Echoing Telnet Option
563 - Comments on the RCTE Telnet Option
560 - Remote Controlled Transmission and Echoing Telnet Option

Протоколы передачи и доступа к файлам (FTP, TFTP, SFTP, NFS)
File Transfer and Access Protocols

1094 - NFS: Network File System Protocol specification
1068 - Background File Transfer Program (BFTP)
1037 - NFILE - a file access protocol
959, 542, 354, 265, 172, 114 - The File Transfer Protocol
949 - FTP Unique-Named Store Command
913 - Simple File Transfer Protocol
906 - Bootstrap Loading Using TFTP
822 - Standard for the Format of ARPA Internet Text Messages
821, 788 - Simple Mail Transfer Protocol
783, 768, 764 - The TFTP Protocol Revision 2
775 - Directory Oriented FTP Commands
743 - FTP Extension: XRSQ/XRCP
737 - FTP Extension: XSEN
697 - CWD Command of FTP
691 - One More Try on the FTP
686 - Leaving Well Enough Alone
683 - FTPSRV -- Tenex Extension for Paged Files
678 - Document File Format Standards
662 - Performance Improvement in ARPANET File Transfers from Multics
640 - Revised FTP Reply Codes
630 - FTP Error Code Usage for More Reliable Mail Service
624 - Comments on the File Transfer Protocol
614 - Response to RFC 607 - Comments on the FTP
607 - NIC-21255 Comments on the File Transfer Protocol
573 - Data and File Transfer - Some Measurement Results
571 - Tenex FTP Problem
535 - Comments on File Access Protocol
532 - The UCSD-CC Server-FTP Facility
520 - Memo to FTP Group (Proposal for File Access Protocol)
506 - An FTP Command Naming Problem
505 - Two Solutions to a File Transfer Access Problem
501 - Un-Muddling "Free File Transfer"
487 - Host-Dependent FTP Parameters
486 - Data Transfer Revisited
480 - Host-Dependent FTP Parameters
479 - Use of FTP by the NIC Journal
478 - FTP Server-Server Interaction - II
475 - FTP and the Network Mail System
468 - FTP Data Compression
463 - FTP Comments and Response to RFC 430
458 - Mail Retrieval via FTP
454 - File Transfer Protocol - Meeting Announcement and a New Proposed Document
448 - Print Files in FTP
438 - FTP Server-Server Interaction
430 - Comments on File Transfer Protocol
418 - Server File Transfer Under TSS/360 at NASA/Ames Research Center
414 - File Transfer Protocols (FTP): Status and Further Comments
412 - User FTP Documentation
385 - Comments on the File Transfer Protocol (RFC 354)
310 - Another Look at Data and File Transfer Protocols
294 - The Use of "Set Data Type" Transaction in the File Transfer Protocol
281 - A Suggested Addition to File Transfer Protocol
269 - Some Experience with File Transfer
264, 171 - The Data Transfer Protocol
250 - Some Thoughts on File Transfer
242 - Data Descriptive Language for Shared Data
238 - Comments on DTP and FTP Protocols
163 - Data Transfer Protocols
141 - Comments on RFC 114 (A File Transfer Protocol)
133 - File Transfer and Error Recovery

Справочная служба имен
Domain Name System

1101 - DNS encoding of network names and other types
1035 - Domain names - implementation and specification
1034 - Domain names - concepts and facilities
1033 - Domain administrators operations guide
1032 - Domain administrators guide
1031 - MILNET name domain transition
974 - Mail Routing and the Domain System
973 - Domain System Changes and Observations
953, 811, 810 - HOSTNAME Protocol
921, 897 - Domain Name System Implementation Schedule
920 - Domain Requirements
883 - Domain Names - Implementation and Specification
882 - Domain Names - Concepts and Facilities
881 - The Domain Names Plan and Schedule
830 - A Distributed System for Internet Name Service
819 - The Domain Naming Convention for Internet User Applications
799 - Internet Name Domains
756 - The NIC Name Server -- A Datagram-Based Information Utility
752 - A Universal Host Table

Почтовая служба и система передачи сообщений (SMTP)
Mail and Message Systems

1153 - Digest message format
1148, 1138 - Mapping between X.400(1988)/ISO 10021 and RFC 822
1137 - Mapping between full RFC 822 and RFC 822 with restricted encoding
1090 - SMTP on X.25
1082 - Post Office Protocol - version 3: Extended service offerings
1081 - Post Office Protocol - version 3
1064 - Interactive Mail Access Protocol: Version 2
1056 - PCMAIL: A distributed mail system for personal computers
1049 - Content-type header field for Internet messages
1047 - Duplicate messages and SMTP
1026 - Addendum to RFC 987: (Mapping between X.400 and RFC-822)
994, 983 - PCMAIL: A Distributed Mail System
977 - Network News Transfer Protocol
976 - UUCP Mail Interchange Format Standard
974 - Mail Routing and the Domain System
934 - Proposed Standard for Message Encapsulation
915 - Network Mail Path Service
886 - Proposed Standard for Message Header Munging
850 - Standard for Interchange of USENET Messages
841 - Specification for Message Format for Computer Based Message Systems
822 - Standard for the Format of ARPA Internet Text Messages
821 - Simple Mail Transfer Protocol
806 - Specification for Message Format for Computer Based Message Systems
780, 772 - Mail Transfer Protocol
786 - Mail Transfer Protocol - ISI TOPS-20 MTP-NIMAIL Interface
785 - Mail Transfer Protocol - ISI TOPS-20 File Definitions
784 - Mail Transfer Protocol - ISI TOPS-20 Implementation
771 - Mail Transition Plan
763 - Role Mailboxes
757 - A Suggested Solution to the Naming, Addressing, and Delivery Problem for ARPANET Message Systems
754 - Out-of-Net Host Addresses for Mail
753 - Internet Message Protocol
751 - Survey of FTP Mail and MLFL
733 - Standard for the Format of ARPA Network Text Messages
724 - Proposed Official Standard for the Format of ARPA Network Messages
720 - Address Specification Syntax for Network Mail
706 - On the Junk Mail Problem
680 - Message Transmission Protocol
644 - On the Problem of Signature Authentication for Network Mail
577 - Mail Priority
574 - Announcement of a Mail Facility at UCSB
561 - Standardizing Network Mail Headers
555 - Responses to Critiques of the Proposed Mail Protocol
539, 524 - A Proposed Mail Protocol
498 - On Mail Service to CCN
491 - What is "Free"?
475 - On FTP and the Network Mail System
458 - Mail Retrieval via FTP
333 - A Proposed Experiment with a Message Switching Protocol
278, 224, 221, 196 - A Mail Box Protocol

Факсимиле
Facsimile

809 - UCL Facsimile System
804 - Facsimile Formats
803 - Dacom 450/500 Facsimile Date Transcoding
798 - Decoding Facsimile Data From the Rapicom 450
797 - Bitmap Formats
769 - Rapicom 450 Facimile File Format

Графические и многооконные системы
Graphics and Window Systems

1013 - X Window System Protocol, version 11: Alpha update April 1987
965 - A Format for a Graphical Communication Protocol
553 - Draft Design for a Text/Graphics Protocol
493 - Graphics Protocol
401 - Conversion of NGP-0 Coordinates to Device Specific Coordinates
398 - UCSB Online Graphics
387 - Some Experiences in Implementing Network Graphics Protocol Level 0
351 - Information Form for the ARPANET Graphics Resources Notebook
336 - Level 0 Graphics Input Protocol
296 - DS-1 Display System
292 - Graphics Protocol - Level 0 only
285 - Network Graphics
268 - Graphics Facilities Information
199 - Suggestions for a Network Data-Telnet Graphics Protocol
192 - Some Factors Which a Network Graphics Protocol Must Consider
191 - Graphics Implementation and Conceptualization at ARC
186 - A Network Graphics Loader
184 - Proposed Graphic Display Modes
181, 177 - A Device Independent Graphical Display Description
178 - Network Graphics Attention Handling
125, 086 - Proposal for a Network Standard Format for a Data Stream to Control Graphics Display
094 - Some Thoughts on Network Graphics

Управление данными
Data Management

304 - A Data Management System Proposal for the ARPA Network
195 - Data Computers - Data Descriptions and Access Language
194 - The Data Reconfiguration Service - Compiler/Interpreter Implementation Notes
166 - Data Reconfiguration Service - An Implementation Specification
144 - Data Sharing on Computer Networks
138 - Status Report on Proposed Data Reconfiguration Service
083 - Language-Machine for Data Reconfiguration

Удаленный ввод заданий (NETRJE, NETRJS)
Remote Job Entry

740, 599, 589, 325, 189, 088 - CCN Network Remote Job Entry Program - NETRJS
725 - An RJE Protocol for a Resource Sharing Network
499 - Harvard's Network RJE
490 - Surrogate RJS for UCLA-CCN
477, 436 - Remote Job Service at UCSB
407 - Remote Job Entry
368 - Comments on "Proposed Remote Job Entry Protocol"
360 - Proposed Remote Job Entry Protocol
338 - EBCDIC/ASCII Mapping for Network RJE
307 - Using Network Remote Job Entry
283 - NETRJT - Remote Job Service Protocol for TIPS
105 - Network Specification for Remote Job Entry and Remote Job Output Retrieval at UCSB

Удаленный вызов процедур (RPC)
Remote Procedure Call

1057 - RPC: Remote Procedure Call Protocol specification version 2
1050 - RPC: Remote Procedure Call Protocol specification

Дата и время (NTP)
Time And Date

1129 - Internet time synchronization: The Network Time Protocol
1128 - Measured performance of the Network Time Protocol in the Internet system
1119 - Network Time Protocol (version 2) specification and implementation
1059 - Network Time Protocol (version 1) specification and implementation
958, 957, 956 - Network Time Protocol
868 - Time Server Protocol
867 - Daytime Protocol
778 - DCNET Time Server Protocol
738 - Time Server
685 - Response Time in Cross-network Debugging
034 - Some Brief Preliminary Notes on the ARC Clock
032 - Some Thoughts on SRI's Proposed Real Time Clock
028 - Time Standards

Представление данных (XDR)
Presentation and Representation

1014 - XDR: External Data Representation standard
1003 - Issues in defining an equations representation standard

Управление в сетях (SNMP, CMOT, MIB)
Network Management

1109 - Report of the second Ad Hoc Network Management Review Group
1095 - Common Management Information Services and Protocol over TCP/IP (CMOT)
1089 - SNMP over Ethernet
1076 - HEMS monitoring and control language
1067 - Simple Network Management Protocol
1156, 1066 - Management Information Base for network management of TCP/IP-based internets
1155, 1065 - Structure and identification of management information for TCP/IP-based internets
1028 - Simple Gateway Monitoring Protocol
1024 - HEMS variable definitions
1023 - HEMS monitoring and control language
1022 - High-level Entity Management Protocol (HEMP)
1021 - High-level Entity Management System (HEMS)

Служба каталогов
Directory Services

1107 - Plan for Internet directory services
1157, 1098 - Simple Network Management Protocol (SNMP)

Протоколы начальной загрузки (BOOTP)
Bootstrap Protocols

1084, 1048 - BOOTP vendor information extensions

Разное
Other

978 - Voice File Interchange Protocol (VFIP)
972 - Password Generator Protocol
954, 812 - Whois Protocol
951 - Bootstrap Protocol
937, 918 - Post Office Protocol
931, 912 - Authentication Service
913 - Simple File Transfer Protocol
909 - Loader Debugger Protocol
891 - DCN Local Net Protocol
887 - Resource Location Protocol
866 - Active Users Protocol
865 - Quote of the Day Protocol
864 - Character Generator Protocol
863, 361, 348 - Discard Protocol
862, 361, 347 - Echo Protocol
821, 822 - Simple Mail Transfer Protocol
783 - Trivial File Transfer Protocol
767 - Document Formats
759 - Internet Message Protocol
742 - Finger Protocol
734 - SUPDUP Protocol
726 - Remote Controlled Transmission and Echoing Telnet Option
666 - Specification of the Unified User-Level Protocol
621 - NIC User Directories at SRI-ARC
569 - Network Standard Text Editor
470 - Change in Socket for TIP News Facility
451 - Tentative Proposal for a Unified User Level Protocol
098, 079 - Logger Protocol
029 - Note in Response to Bill English's Request for Comments

Документация к программам
Program Documentation

496 - A TNLS Quick Reference Card is Available
494 - Availability of MIX and MIXAL in the Network
488 - NLS Classes at Network Sites
485 - MIS and MIXAL at UCSB
431 - Update on SMFS Login and Logout
411 - New Multics Network Software Features
409 - TENEX Interface to UCSB's Simple-Minded File System
399 - SMFS Login and Logout
390 - TSO Scenario Batch Compilation and Foreground Execution
382 - Mathematical Software on the ARPA Network
379 - Using TSO at CCN
373 - Arbitrary Character Sets
350 - User Accounts for UCSB On-Line System
345 - Interest Mixed Integer Programming (MPSX on 360/91 at CCN)
321 - CBI Networking Activity at MITRE
317 - Official Host-Host Protocol Modification: Assigned Link Numbers
311 - New Console Attachments to the UCSB Host
251 - Weather Data
223 - Network Information Center Schedule for Network Users
217 - Specification Changes for OLS, RJE/RJOR, and SMFS
174 - UCLA-Computer Science Graphics Overview
122 - Network Specifications for UCSB's Simple-Minded File System
121 - Network On-Line Operators
120 - Network PL1 Subprograms
119 - Network FORTRAN Subprograms
074 - Specifications for Network Use of the UCSB On-Line System

Особенности некоторых сетей
Network Specific

Сеть ARPANET

1005, 878, 851, 802 - The ARPANET 1822L Host Access Protocol
852 - The ARPANET Short Blocking Feature
789 - Vulnerabilities of Network Control Protocols: An Example
716 - Interim Revision to Appendix F of BBN 1822
704 - IMP/Host and Host/IMP Protocol Change
696 - Comments on the IMP/HOST and HOST/IMP Protocol Changes
695 - Official Change in Host-Host Protocol
692 - Comments on IMP/Host Protocol Changes
690 - Comments on the Proposed Host/IMP Protocol Changes
687 - IMP/Host and Host/IMP Protocol
667 - BBN Host Ports
660 - Some Changes to the IMP and the IMP/Host Interface
642 - Ready Line Philosophy and Implementation
638, 633 - IMP/TIP Preventive Maintenance Schedule
632 - Throughput Degradation for Single Packet Message
627 - ASCII Text File of Hostnames
626 - On a possible Lockup Condition in IMP Subnet due to Message Sequencing
625 - On Line Hostnames Service
623 - Comments on On-line Host Name Service
622 - Scheduling IMP/TIP Down Time
620 - Request for Monitor Host Table Updates
619 - Mean Round-Trip Times in the ARPANET
613 - Network Connectivity: A Response to RFC 603
611 - Two Changes to the IMP/Host Protocol
606 - Host Names On-Line
594 - Speedup of Host-IMP Interface
591 - Addition to the Very Distant Host Specification
568, 567 - Cross-Country Network Bandwidth
548 - Hosts Using the IMP Going Down Message Specification
547 - Change to the Very Distant Host Specification
533 - Message-ID Numbers
534 - Lost Message Detection
528 - Software Checksumming in the IMP and Network Reliability
521 - Restricted Use of IMP DDT
508 - Real-Time Data Transmission on the ARPANET
476, 434 - IMP/TIP Memory Retrofit Schedules
449, 442 - The Current Flow-Control Scheme for IMPSYS
447, 445 - IMP/TIP Preventive Maintenance Schedule
417 - LINK Usage Violation
410 - Removal of the 30-second Delay When Hosts Come Up
406 - Scheduled IMP Software Releases
395 - Switch Settings on IMPs and TIPs
394 - Two Proposed Changes to the IMP-HOST Protocol
369- Evaluation of ARPANET Services (January through March, 1972)
335 - New Interface-IMP/360
312 - Proposed Change in IMP-to-Host Protocol
297 - TIP Message Buffers
280 - A Draft Set of Host Names
274 - Establishing a Local Guide for Network Usage
271 - IMP System Change Notification
270 - Correction to the BBN Report No. 1822
263 - "Very Distant" Host Interface
254 - Scenarios for Using ARPANET Computers
247 - Proffered Set of Standard Host Names
241 - Connecting Computers to NLC Ports
239 - Host Mnemonics Proposed in RFC 226
237 - The NIC's View of Standard Host Names
236 - Standard Host Names
233 - Standardization of Host Call Letters
230 - Toward Reliable Operation of Minicomputer-based Terminals on a TIP
229 - Standard Host Names
228 - Clarification
226 - Standardization of Host Mnemonics
218 - Changing the IMP Status Reporting
213 - IMP System Change Notification
209 - Host/IMP Interface Documentation
208 - Address Tables
073, 067 - Proposed Change to Host/IMP Spec to Eliminate Marking
071 - Reallocation in Case of Input Error
070 - A Note On Padding
064 - Getting Rid of Marking
041 - IMP/IMP Teletype Communication
025 - No High Link Numbers
019 - Two Protocol Suggestions to Reduce Congestion at Swap-Bound Nodes
017a, 017 - Some Questions Re: HOST-IMP Protocol
012 - IMP-HOST Interface Flow Diagrams
007 - HOST-IMP Interface
006 - Conversation with Bob Kahn

Протоколы сетевого доступа
Host Front End Protocols

929, 928, 705, 647 - Host-Front End Protocol

Протокол NCP сети ARPANET (предшественник TCP/IP)
ARPANET NCP (Obsolete predecessor of TCP/IP)

801 - NCP/TCP Transition Plan
773 - Comments on NCP/TCP Mail Service Transition Strategy
714 - A Host/Host Protocol for an ARPANET-type Network
689 - Tenex NCP Finite State Machine for Connections
663 - A Lost Message Detection and Recovery Protocol
636 - TIP/TENEX Reliability Improvements
635 - An Assessment of ARPANET Protocols
534, 516, 512 - Lost Message Detection
492, 467 - Proposed Change to Host-Host Protocol Resynchronization of Connection Status
489 - Comment on Resynchronization of Connection Status Proposal
425 - "But my NCP Costs $500 a day..."
210 - Improvement of Flow Control
197 - Initial Connection Protocol - Revised
176 - Comments on Byte Size for Connections
165 - A Proferred Official Initial Connection Protocol
147 - The Definition of a Socket
142 - Time-out Mechanism in the Host-Host Protocol
132, 124, 107, 102 - Output of the Host-Host Protocol Glitch Cleaning Committee
129 - A Request for Comments on Socket Name Structure
128 - Bytes
117 - Some Comments on the Official Protocol
072 - Proposed Moratorium on Changes to Network Protocol
068 - Comments on Memory Allocation Control Commands (CEASE, ALL, GVB, RET) and RFNM
065 - Comments on Host-Host Protocol Document Number 1
060 - A Simplified NCP Protocol
059 - Flow Control-Fixed Versus Demand Allocation
058 - Logical Message Synchronization
057, 054 - An Official Protocol Proffering
056 - Third Level Protocol
055 - A Prototypical Implementation of the NCP
050, 049, 048, 047, 046, 045, 044, 040, 039, 038, 036, 033 - New Host-Host Protocol
042 - Message Data Types
023 - Transmission of Multiple Control Messages
022 - Host-Host Control Message Formats
018 - Comments Re: Host-Host control link
015 - Network Subsystem for Time Sharing Hosts
011 - Implementation of the Host-Host Software Procedures in GORDO
009, 001 - Host Software
008 - ARPA Network Functional Specifications
005 - DEL
002 - Links

Протокол ICP сети ARPANET
ARPANET Initial Connection Protocol

202 - Possible Deadlock in ICP
197 - Initial Connection Protocol - Revised
161 - A Solution to the Race Condition in the ICP
151, 148, 143, 127, 123 - A Proferred Official ICP
150 - The Use of IPC Facilities
145 - Initial Connection Protocol Control Commands
093 - Initial Connection Protocol
080 - Protocol and Data Formats
066 - 3rd Level Ideas and Other Noise

Сеть USENET

1036 - Standard for interchange of USENET messages

Разное
Other

1132 - Standard for the transmission of 802.2 packets over IPX networks
935 - Reliable Link Layer Protocols
916 - Reliable Asynchronous Transfer Protocol
914 - Thinwire Protocol
824 - The Cronus Virtual Local Network

Измерение
Measurement

Общие вопросы
General

573 - Data and File Transfer - Some Measurement Results
557 - Revelations in Network Host Measurements
546 - Tenex Load Averages for July 1973
462 - Responding to User Needs
415 - TENEX Bandwidth
392 - Measurement of Host Costs for Transmitting Network Data
352 - TIP Site Information Form
308 - ARPANET Host Availability Data
286 - Network Library Information System
274 - Establishing a Local Guide for Network Usage
214, 193 - Network Checkout
198 - Site Certification - Lincoln Labs
182 - Compilation of List of Revelant Site Reports
180 - File System Questionnaire
156 - Status of the Illinois Site (Response to RFC 116)
153 - SRI ARC-NIC Status
152 - SRI Artificial Intelligence Status Report
126 - Ames Graphics Facilities at Ames Research Center
112 - User/Server Site Protocol Network HOST Questionnaire
104 - Link 191
106 - USER/SERVER Site Protocol Network Host Questionnaire

Обзоры
Surveys

971 - A Survey of Data Representation Standards
876 - Survey of SMTP Implementations
848 - Who Provides the "Little" TCP Services?
847 - Summary of Smallberg Surveys
844 - Who Talks ICMP, too? Survey of 18 February 1983
846, 845, 843, 842, 839, 838, 837, 836, 835, 834, 833, 832 - Who Talks TCP?
787 - Connectionless Data Transmission Survey/Tutorial
703, 702, 701, 679, 669 - Survey of New-Protocol Telnet Servers
565 - Storing Network Survey Data at the Datacomputer
545 - Of What Quality be the UCSB Resource Evaluators?
530 - A Report on the SURVEY Project
523 - SURVEY is in Operation Again
519 - Resource Evaluation
514 - Network Make-Work
464 - Resource Notebook Framework
460 - NCP Survey
459 - Network Questionnaire
450 - Multics Sampling Timeout Change
446 - Proposal to Consider a Network Program Resource Notebook
096 - An Interactive Network Experiment to Study Modes of Access to the Network Information Center
090 - CCN as a Network Service Center
081 - Request for Reference Information
078 - NCP Status Report: UCSB/Rand

Статистика
Statistics

1128 - Measured performance of the Network Time Protocol in the Internet system
1030 - On testing the NETBLT Protocol over divers networks
996 - Statistics Server
618 - A Few Observations on NCP Statistics
612, 601, 586, 579, 566, 556, 538, 522, 509, 497, 482, 455, 443, 422, 413, 400, 391, 378 - Traffic Statistics
603, 597, 376, 370, 367, 366, 362, 352, 344, 342, 332, 330, 326, 319, 315, 306, 298, 293, 288, 287, 267, 266 - Network Host Status
550 - NIC NCP Experiment
388 - NCP Statistics
255, 252, 240, 235 - Site Status

Безопасность и конфиденциальность
Privacy And Security

1135 - Helminthiasis of the Internet
1115 - Privacy enhancement for Internet electronic mail: Part III - algorithms, modes, and identifiers [Draft]
1114 - Privacy enhancement for Internet electronic mail: Part II - certificate-based key management [Draft]
1113 - Privacy enhancement for Internet electronic mail: Part I - message encipherment and authentication procedures [Draft]
1040 - Privacy enhancement for Internet electronic mail: Part I: Message encipherment and authentication procedures
1038 - Draft revised IP security option
1004 - Distributed-protocol authentication scheme

Опыт в области сетей
Network Experience and Demonstrations

968 - 'Twas the Night Before Start-up
967 - All Victims Together
573 - Data and File Transfer - Some Measurement Results
527 - ARPAWOCKY
525 - MIT-Mathlab Meets UCSB-OLS
439 - PARRY Encounters the Doctor
420 - CCA ICC Weather Demo
372 - Notes on a Conversation with Bob Kahn on the ICCC
364 - Serving Remote Users on the ARPANET
302 - Excercising the ARPANET
231 - Service Center Standards for Remote Usage - A User's View
227 - Data Transfer Rates (RAND/UCLA)
113 - Network Activity Report: UCSB and Rand
089 - Some Historic Moments in Networking
004 - Network Timetable

О документации
Site Documentation

030, 027, 024, 016, 010, 003 - Documentation Conventions

Стандарты организаций, не связанных с IAB
Protocol Standards By Other Groups Of Interest

ANSI

570 - Experimental Input Mapping Between NVT ASCII and UCSB Online System
183 - The EBCDIC Codes and Their Mapping to ASCII
020 - ASCII Format for Network Interchange

CCITT

987 - Mapping Between X.400 and RFC 822
874 - A Critique of X.25

NRC

942 - Transport Protocols for Department of Defense Data Networks
939 - Executive Summary of the NRC Report on Transport Protocols for Department of Defense Data Networks

ISO

1139 - Echo function for ISO 8473
1008 - Implementation guide for the ISO Transport Protocol
1007 - Military supplement to the ISO Transport Protocol
995 - End System to Intermediate System Routing Exchange Protocol for Use in Conjunction with ISO 8473
994 - Final Text of DIS 8473, Protocol for Providing the Connectionless Mode Network Service
982 - Guidelines for the Specification of the Structure of the Domain Specific Part (DSP) of the ISO Standard NSAP Address
941 - Addendum to the Network Service Definition Covering Network Layer Addressing
926 - Protocol for Providing the Connectionless-Mode Network Services
905 - ISO Transport Protocol Specification (ISO DP 8073)
892 - ISO Transport Protocol
873 - The Illusion of Vendor Support

Взаимодействие с протоколами, не входящими в семейство TCP/IP
Interoperability With Other Protocols

Согласование протоколов и мосты
Protocol Translation And Bridges

1086 - ISO-TP0 bridge between TCP and X.25
1029 - More fault tolerant approach to address resolution for a Multi-LAN system of Ethernets

Согласование уровней протоколов
Tunneling And Layering

1090 - SMTP on X.25
1089 - SNMP over Ethernet
1085 - ISO presentation services on top of TCP/IP based internets
1070 - Use of the Internet as a subnetwork for experimentation with the OSI network layer
1006 - ISO transport services on top of TCP: Version: 3
1002 - Protocol standard for a NetBIOS service on a TCP/UDP transport: Detailed specifications
1001 - Protocol standard for a NetBIOS service on a TCP/UDP transport: Concepts and methods

Отображение имен, адресов и идентификаторов
Mapping of Names, Addresses and Identifiers

1148, 1138 - Mapping between X.400(1988)/ISO 10021 and RFC 822
1069 - Guidelines for the use of Internet-IP addresses in the ISO Connectionless-Mode Network Protocol
1026 - Addendum to RFC 987: (Mapping between X.400 and RFC-822)
987 - Mapping Between X.400 and RFC 822

Разное
Miscellaneous

1121 - Act one - the poems
1118 - Hitchhikers guide to the Internet
1015 - Implementation plan for interagency research Internet

Неклассифицированные RFC
Unissued

Старые документы
Never Issued

014, 026, 092, 159, 201, 220, 244, 248, 257, 258, 259, 260, 261, 262, 272, 275, 277, 279, 284, 337, 341, 358, 375, 380, 383, 397, 424, 427, 428, 444, 465, 481, 484, 502, 507, 517, 536, 540, 541, 554, 558, 564, 572, 575, 583, 605, 639, 641, 646, 648, 649, 650, 664, 665, 668, 670, 673, 676, 682, 693, 709, 710, 711, 715, 723, 853

Новые документы
Not yet Issued

1060, 1061, 1099, 1108, 1140, 1142, 1147


Приложение 2. Стандарты семейства протоколов TCP/IP

Internet Activities Board (IAB) присваивает протоколам семейства TCP/IP состояние и статус. Везде далее под словом "стандарт" мы будем иметь в виду стандарт IAB.

IAB - Совет по развитию сети Internet

Состояния протоколов

Состояние           Значение
=================   =================================================
Предлагаемый        Протокол был предложен в качестве стандарта
протокол            и находится в стадии начального рассмотрения.

Предварительный Протокол прошел
начальное рассмотрение и стандарт
находится в почти законченном виде.
Существуют по крайней мере две
независимых реализации.

Стандартный Протокол пересмотрен
и принят как полный протокол
стандарт. Он является составной
частью TCP/IP.

Экспериментальный Протокол пока
не предлагался для стандартизации,
протокол но используется в
экспериментах.

Ознакомительный Протокол
разработан сторонней организацией
и протокол находится вне
компетенции IAB. Он может быть
опубликован в виде RFC для
ознакомления.

Устаревший Протокол устарел и в
нстоящее время не протокол
используется.

Статус протокола

Статус              Значение
=================   =================================================
Обязательный        Все узлы и шлюзы, использующие TCP/IP,
                    должны реализовывать этот протокол.

Рекомендуемый Поощряется
использование данного протокола во
всех узлах и шлюзах.

Выбираемый Узлы и шлюзы могут
реализовывать этот протокол.

Ограниченного Протокол не
предназначен для широкого
пользования использования,
например, он может быть
экспериментальным.

Нерекомендуемый Данным
протоколом пользоваться не
рекомендуется. Например, не
рекомендуются устаревшие
протоколы.

Стандартные протоколы Standard Protocols

Протокол   Название                                  Статус       RFC
========   =====================================     =========== ====
--------   Assigned Numbers                          Об.         1060
--------   Gateway Requirements                      Об.         1009
--------   Host Requirements - Communications        Об.         1122
--------   Host Requirements - Applications          Об.         1123
IP         Internet Protocol                         Об.          791
            с расширениями:
--------     IP Subnet Extension                     Об.          950
--------     IP Broadcast Datagrams                  Об.          919
--------     IP Broadcast Datagrams with Subnets     Об.          922
ICMP       Internet Control Message Protocol         Об.          792
IGMP       Internet Group Multicast Protocol         Рек.        1112
UDP        User Datagram Protocol                    Рек.         768
TCP        Transmission Control Protocol             Рек.         793
SMI        Structure of Management Information       Рек.        1155
MIB        Management Information Base               Рек.        1156
SNMP       Simple Network Management Protocol        Рек.        1157
DOMAIN     Domain Name System                        Рек.   1034,1035
TELNET     Telnet Protocol                           Рек.         854
FTP        File Transfer Protocol                    Рек.         959
SMTP       Simple Mail Transfer Protocol             Рек.         821
MAIL       Format of Electronic Mail Messages        Рек.         822
CONTENT    Content Type Header Field                 Рек.        1049
EGP        Exterior Gateway Protocol                 Рек.         904
ECHO       Echo Protocol                             Рек.         862
NTP        Network Time Protocol                     Рек.        1119
NETBIOS    NetBIOS Service Protocols                 Выб.   1001,1002
DISCARD    Discard Protocol                          Выб.         863
CHARGEN    Character Generator Protocol              Выб.         864
QUOTE      Quote of the Day Protocol                 Выб.         865
USERS      Active Users Protocol                     Выб.         866
DAYTIME    Daytime Protocol                          Выб.         867
TIME       Time Server Protocol                      Выб.         868

Стандартные протоколы разных сетей Network-Specific Standard Protocols

Протокол   Название                                 Статус        RFC
========   =====================================    ============ ====
ARP        Address Resolution Protocol              Выб.          826
RARP       A Reverse Address Resolution Protocol    Выб.          903
IP-ARPA    Internet Protocol on ARPANET             Выб.     BBN 1822
IP-WB      Internet Protocol on Wideband Network    Выб.          907
IP-X25     Internet Protocol on X.25 Networks       Выб.          877
IP-E       Internet Protocol on Ethernet Networks   Выб.          894
IP-EE      Internet Protocol on Exp. Ethernet Nets  Выб.          895
IP-IEEE    Internet Protocol on IEEE 802            Выб.         1042
IP-DC      Internet Protocol on DC Networks         Выб.          891
IP-HC      Internet Protocol on Hyperchannel        Выб.         1044
IP-ARC     Internet Protocol on ARCNET              Выб.         1051
IP-SLIP    Transmission of IP over Serial Lines     Выб.         1055
IP-NETBIOS Transmission of IP over NETBIOS          Выб.         1088
IP-FDDI    Transmission of IP over FDDI             Выб.         1103
IP-IPX     Transmission of 802.2 over IPX Networks  Выб.         1132

Предварительные стандарты протоколов Draft Standard Protocols

Протокол   Название                                 Статус        RFC
========   =====================================    ============ ====
FINGER     Finger Protocol                          Выб.         1196
IP-FDDI    Internet Protocol on FDDI Networks       Выб.         1188
TOPT-LINE  Telnet Linemode Option                   Выб.         1184
MIB-II     MIB-II                                   Выб.         1213
PPP        Point to Point Protocol                  Выб.         1171
--------   Mail Privacy: Procedures                 Выб.         1113
--------   Mail Privacy: Key Management             Выб.         1114
--------   Mail Privacy: Algorithms                 Выб.         1115
BOOTP      Bootstrap Protocol                       Выб.951,1048,1084
RIP        Routing Information Protocol             Выб.         1058
TP-TCP     ISO Transport Service on top of the TCP  Выб.         1006
NICNAME    WhoIs Protocol                           Выб.          954
TFTP       Trivial File Transfer Protocol           Выб.          783

Предлагаемые стандарты протоколов Proposed Standard Protocols

Протокол   Название                                 Статус        RFC
========   =====================================    ============ ====
OIM-MIB-II OSI Internet Management: MIB-II          Выб.         1214
Concise-MIB Concise MIB Definitions                 Выб.         1212
IP-SMDS    IP Datagrams over the SMDS Service       Выб.         1209
IP-ARCNET  Transmitting IP Traffic over ARCNET Networks Выб.     1201
IS-IS      Use of OSI IS-IS for Routing in TCP/IP   Выб.         1195
           and Dual Environments
IP-MTU     Path MTU Discovery                       Выб.         1191
CMOT       Common Management Information Services   Выб.         1189
           and Protocol over TCP/IP
PPP-INIT   PPP Initial Configuration Options        Выб.         1172
BGP        Border Gateway Protocol                  Выб.    1163,1164
IP-CMPRS   Compressing TCP/IP Headers               Выб.         1144
--------   Echo for ISO-8473                        Выб.         1139
OSPF       Open Shortest Path First Routing         Выб.         1131
TOPT-ENV   Telnet Environment Option                Выб.         1116
SUN-NFS    Network File System Protocol             Выб.         1094
POP3       Post Office Protocol, Version 3          Выб.    1081,1082
SUN-RPC    Remote Procedure Call Protocol           Выб.         1057
PCMAIL     Pcmail Transport Protocol                Выб.         1056
NFILE      A File Access Protocol                   Выб.         1037
--------   Mapping between X.400(84) and RFC-822    Выб.     987,1026
NNTP       Network News Transfer Protocol           Выб.          977
HOSTNAME   HOSTNAME Protocol                        Выб.          953
SFTP       Simple File Transfer Protocol            Выб.          913
RLP        Resource Location Protocol               Выб.          887
SUPDUP     SUPDUP Protocol                          Выб.          734

Экспериментальные протоколы Experimental Protocols

Протокол   Название                                 Статус        RFC
========   =====================================    ============ ====
MPP        Message Posting Protocol                 Огр.         1204
ST-II      Stream Protocol                          Огр.         1190
SNMP-BULK  Bulk Table Retrieval with the SNMP       Огр.         1187
DNS-RR     New DNS RR Definitions                   Огр.         1183
NTP-OSI    NTP over OSI Remote Operations           Огр.         1165
MSP        Message Send Protocol                    Огр.         1159
EHF-MAIL   Encoding Header Field for Mail           Выб.         1154
DMF-MAIL   Digest Message Format for Mail           Выб.         1153
RDP        Reliable Data Protocol                   Огр.     908,1151
--------   Mapping between X.400(88) and RFC-822    Выб.         1148
TCP-ACO    TCP Alternate Checksum Option            Нерек.       1146
--------   Mapping full 822 to Restricted 822       Выб.         1137
IP-DVMRP   IP Distance Vector Multicast Routing     Нерек.       1075
TCP-LDP    TCP Extensions for Long Delay Paths      Огр.         1072
IMAP2      Interactive Mail Access Protocol         Огр.    1176,1064
IMAP3      Interactive Mail Access Protocol         Огр.         1203
VMTP       Versatile Message Transaction Protocol   Выб.         1045
COOKIE-JAR Authentication Scheme                    Нерек.       1004
NETBLT     Bulk Data Transfer Protocol              Нерек.        998
IRTP       Internet Reliable Transaction Protocol   Нерек.        938
AUTH       Authentication Service                   Нерек.        931
LDP        Loader Debugger Protocol                 Нерек.        909
NVP-II     Network Voice Protocol                   Огр.     ISI-memo
PVP        Packet Video Protocol                    Огр.     ISI-memo

Ознакомительные протоколы Informational Protocols

Протокол   Название                                               RFC
=======    =====================================                 ====
SNMP-TRAPS A Convention for Defining Traps for use with SNMP     1215
DAS        Directory Assistance Service                          1202
-------    FYI on the X Window System                            1198
ODA        Office Document Architecture                          1197
MD4        MD4 Message Digest Algorithm                          1186
LPDP       Line Printer Daemon Protocol                          1179

Устаревшие протоколы  Historic Protocols

Протокол   Название                                 Статус        RFC
=======    =====================================    ============ ====
SGMP       Simple Gateway Monitoring Protocol       Нерек.       1028
HEMS       High Level Entity Management Protocol    Нерек.       1021
STATSRV    Statistics Server                        Нерек.        996
POP2       Post Office Protocol, Version 2          Нерек.        937
RATP       Reliable Asynchronous Transfer Protocol  Нерек.        916
THINWIRE   Thinwire Protocol                        Нерек.        914
HMP        Host Monitoring Protocol                 Нерек.        869
GGP        Gateway Gateway Protocol                 Нерек.        823
RTELNET    Remote Telnet Service                    Нерек.        818
CLOCK      DCNET Time Server Protocol               Нерек.        778
MPM        Internet Message Protocol                Нерек.        759
NETRJS     Remote Job Service                       Нерек.        740
NETED      Network Standard Text Editor             Нерек.        569
RJE        Remote Job Entry                         Нерек.        407
XNET       Cross Net Debugger                       Нерек.    IEN-158
NAMESERVER Host Name Server Protocol                Нерек.    IEN-116
MUX        Multiplexing Protocol                    Нерек.     IEN-90
GRAPHICS   Graphics Protocol                        Нерек.  NIC-24308


Протоколы прикладного уровня

Почему существуют два транспортных протокола TCP и UDP, а не один из них? Дело в том, что они предоставляют разные услуги прикладным процессам. Большинство прикладных программ пользуются только одним из них. Вы, как программист, выбираете тот протокол, который наилучшим образом соответствует вашим потребностям. Если вам нужна надежная доставка, то лучшим может быть TCP. Если вам нужна доставка датаграмм, то лучше может быть UDP. Если вам нужна эффективная доставка по длинному и ненадежному каналу передачи данных, то лучше может подойти протокол TCP. Если нужна эффективность на быстрых сетях с короткими соединениями, то лучшим может быть протокол UDP. Если ваши потребности не попадают ни в одну из этих категорий, то выбор транспортного протокола не ясен. Однако прикладные программы могут устранять недостатки выбранного протокола. Например, если вы выбрали UDP, а вам необходима надежность, то прикладная программа должна обеспечить надежность. Если вы выбрали TCP, а вам нужно передавать записи, то прикладная программа должна вставлять маркеры в поток байтов так, чтобы можно было различить записи.

Какие же прикладные программы доступны в сетях с TCP/IP?

Общее их количество велико и продолжает постоянно увеличиваться. Некоторые приложения существуют с самого начала развития internet. Например, TELNET и FTP. Другие появились недавно: X-Window, SNMP.

Протоколы прикладного уровня ориентированы на конкретные прикладные задачи. Они определяют как процедуры по организации взаимодействия определенного типа между прикладными процессами, так и форму представления информации при таком взаимодействии. В этом разделе мы коротко опишем некоторые из прикладных протоколов.

Протокол TELNET

Протокол TELNET позволяет обслуживающей машине рассматривать все удаленные терминалы как стандартные "сетевые виртуальные терминалы" строчного типа, работающие в коде ASCII, а также обеспечивает возможность согласования более сложных функций (например, локальный или удаленный эхо-контроль, страничный режим, высота и ширина экрана и т.д.) TELNET работает на базе протокола TCP. На прикладном уровне над TELNET находится либо программа поддержки реального терминала (на стороне пользователя), либо прикладной процесс в обсуживающей машине, к которому осуществляется доступ с терминала.

Работа с TELNET походит на набор телефонного номера. Пользователь набирает на клавиатуре что-то вроде

telnet delta

и получает на экране приглашение
на вход в машину delta.

Протокол TELNET существует уже
давно. Он хорошо опробован и широко
распространен. Создано множество
реализаций для самых разных
операционных систем. Вполне
допустимо, чтобы процесс-клиент
работал, скажем, под управлением ОС
VAX/VMS, а процесс-сервер под ОС UNIX System
V.

Протокол FTP

Протокол FTP (File Transfer Protocol -
протокол передачи файлов)
распространен также широко как TELNET.
Он является одним из старейших
протоколов семейства TCP/IP. Также как
TELNET он пользуется транспортными
услугами TCP. Существует множество
реализаций для различных
операционных систем, которые
хорошо взаимодействуют между
собой. Пользователь FTP может
вызывать несколько команд, которые
позволяют ему посмотреть каталог
удаленной машины, перейти из одного
каталога в другой, а также
скопировать один или несколько
файлов.

Протокол SMTP

Протокол SMTP (Simple Mail Transfer Protocol -
простой протокол передачи почты)
поддерживает передачу сообщений
(электронной почты) между
произвольными узлами сети internet.
Имея механизмы промежуточного
хранения почты и механизмы
повышения надежности доставки,
протокол SMTP допускает
использование различных
транспортных служб. Он может
работать даже в сетях, не
использующих протоколы семейства
TCP/IP. Протокол SMTP обеспечивает как
группирование сообщений в адрес
одного получателя, так и
размножение нескольких копий
сообщения для передачи в разные
адреса. Над модулем SMTP
располагается почтовая служба
конкретных вычислительных систем.

r-команды

Существует целая серия
"r-команд" (от remote - удаленный),
которые впервые появились в ОС UNIX.
Они являются аналогами обычных
команд UNIX, но предназначены для
работы с удаленными машинами.
Например, команда rcp является
аналогом команды cp и предназначена
для копирования файлов между
машинами. Для передачи файла на
узел delta достаточно ввести

rcp file.c delta:

Для выполнения команды "cc
file.c" на машине delta можно
использовать команду rsh:

rsh delta cc file.c

Для организации входа в удаленную
систему предназначена команда rlogin:

rlogin delta

Команды r-серии используются
главным образом в системах,
работающих под управлением ОС UNIX.
Существуют также реализации для
MS-DOS. Команды избавляют
пользователя от необходимости
набирать пароли при входе в
удаленную систему и существенно
облегчают работу.

NFS

Сетевая файловая система NFS (Network
File System) впервые была разработана
компанией Sun Microsystems Inc. NFS использует
транспортные услуги UDP и позволяет
монтировать в единое целое
файловые системы нескольких машин
с ОС UNIX. Бездисковые рабочие
станции получают доступ к дискам
файл-сервера так, как будто это их
локальные диски.

NFS значительно увеличивает
нагрузку на сеть. Если в сети
используются медленные линии
связи, то от NFS мало толку. Однако,
если пропускная способность сети
позволяет NFS нормально работать, то
пользователи получают большие
преимущества. Поскольку сервер и
клиент NFS реализуются в ядре ОС, все
обычные несетевые программы
получают возможность работать с
удаленными файлами, расположенными
на подмонтированных NFS-дисках,
точно также как с локальными
файлами.

Протокол SNMP

Протокол SNMP (Simple Network Management Protocol -
простой протокол управления сетью)
работает на базе UDP и предназначен
для использования сетевыми
управляющими станциями. Он
позволяет управляющим станциям
собирать информацию о положении
дел в сети internet. Протокол
определяет формат данных, их
обработка и интерпретация остаются
на усмотрение управляющих станций
или менеджера сети.

X-Window

Система X-Window использует протокол
X-Window, который работает на базе TCP,
для многооконного отображения
графики и текста на растровых
дисплеях рабочих станций. X-Window - это
гораздо больше, чем просто утилита
для рисования окон; это целая
философия человеко-машинного
взаимодействия.


Протокол ARP

В этом разделе мы рассмотрим то, как при посылке IP-пакета определяется Ethernet-адрес назначения. Для отображения IP-адресов в Ethernet адреса используется протокол ARP (Address Resolution Protocol - адресный протокол). Отображение выполняется только для отправляемых IP-пакетов, так как только в момент отправки создаются заголовки IP и Ethernet.

ARP-таблица для преобразования адресов

Преобразование адресов выполняется путем поиска в таблице. Эта таблица, называемая ARP-таблицей, хранится в памяти и содержит строки для каждого узла сети. В двух столбцах содержатся IP- и Ethernet-адреса. Если требуется преобразовать IP-адрес в Ethernet-адрес, то ищется запись с соответствующим IP-адресом. Ниже приведен пример упрощенной ARP-таблицы.

IP-адрес | Ethernet-адрес
223.1.2.1 223.1.2.3 223.1.2.4 | 08:00:39:00:2F:C3 08:00:5A:21:A7:22 08:00:10:99:AC:54

Табл.1. Пример ARP-таблицы
Принято все байты 4-байтного IP-адреса записывать десятичными числами, разделенными точками. При записи 6-байтного Ethernet-адреса каждый байт указывается в 16-ричной системе и отделяется двоеточием.

ARP-таблица необходима потому, что IP-адреса и Ethernet-адреса выбираются независимо, и нет какого-либо алгоритма для преобразования одного в другой. IP-адрес выбирает менеджер сети с учетом положения машины в сети internet. Если машину перемещают в другую часть сети internet, то ее IP-адрес должен быть изменен. Ethernet-адрес выбирает производитель сетевого интерфейсного оборудования из выделенного для него по лицензии адресного пространства. Когда у машины заменяется плата сетевого адаптера, то меняется и ее Ethernet-адрес.

Порядок преобразования адресов

В ходе обычной работы сетевая программа, такая как TELNET, отправляет прикладное сообщение, пользуясь транспортными услугами TCP. Модуль TCP посылает соответствующее транспортное сообщение через модуль IP. В результате составляется IP-пакет, который должен быть передан драйверу Ethernet. IP-адрес места назначения известен прикладной программе, модулю TCP и модулю IP. Необходимо на его основе найти Ethernet-адрес места назначения. Для определения искомого Ethernet-адреса используется ARP-таблица.

Запросы и ответы протокола ARP

Как же заполняется ARP-таблица? Она заполняется автоматически модулем ARP, по мере необходимости. Когда с помощью существующей ARP-таблицы не удается преобразовать IP-адрес, то происходит следующее:

  1. По сети передается широковещательный ARP-запрос.
  2. Исходящий IP-пакет ставится в очередь.

Каждый сетевой адаптер принимает широковещательные передачи. Все драйверы Ethernet проверяют поле типа в принятом Ethernet-кадре и передают ARP-пакеты модулю ARP. ARP-запрос можно интерпретировать так: "Если ваш IP-адрес совпадает с указанным, то сообщите мне ваш Ethernet-адрес". Пакет ARP-запроса выглядит примерно так:

IP-адрес отправителя Ethernet-адрес отправителя | 223.1.2.1 08:00:39:00:2F:C3
Искомый IP-адрес Искомый Ethernet-адрес | 223.1.2.2 <пусто>

Табл.2. Пример ARP-запроса

Каждый модуль ARP проверяет поле искомого IP-адреса в полученном ARP-пакете и, если адрес совпадает с его собственным IP-адресом, то посылает ответ прямо по Ethernet-адресу отправителя запроса. ARP-ответ можно интерпретировать так: "Да, это мой IP-адрес, ему соответствует такой-то Ethernet-адрес". Пакет с ARP-ответом выглядит примерно так:

IP-адрес отправителя Ethernet-адрес отправителя | 223.1.2.2 08:00:28:00:38:A9
Искомый IP-адрес Искомый Ethernet-адрес | 223.1.2.1 08:00:39:00:2F:C3

Табл.3. Пример ARP-ответа Этот ответ получает машина, сделавшая ARP-запрос. Драйвер этой машины проверяет поле типа в Ethernet-кадре и передает ARP-пакет модулю ARP. Модуль ARP анализирует ARP-пакет и добавляет запись в свою ARP-таблицу.

Обновленная таблица выглядит следующим образом:

IP-адрес | Ethernet-адрес
223.1.2.1 223.1.2.2 223.1.2.3 223.1.2.3 | 08:00:39:00:2F:C3 08:00:28:00:38:A9 08:00:5A:21:A7:22 08:00:10:99:AC:54

Табл.4. ARP-таблица после обработки ответа

Продолжение преобразования адресов

Новая запись в ARP-таблице появляется автоматически, спустя несколько миллисекунд после того, как она потребовалась. Как вы помните, ранее на шаге 2 исходящий IP-пакет был поставлен в очередь. Теперь с использованием обновленной ARP-таблицы выполняется преобразование IPадреса в Ethernet-адрес, после чего Ethernet-кадр передается по сети. Полностью порядок преобразования адресов выглядит так:

  1. По сети передается широковещательный ARP-запрос.
  2. Исходящий IP-пакет ставится в очередь.
  3. Возвращается ARP-ответ, содержащий информацию о соответствии IP- и Ethernet-адресов. Эта информация заносится в ARP-таблицу.
  4. Для преобразования IP-адреса в Ethernet-адрес у IP-пакета, постав ленного в очередь, используется ARP-таблица.
  5. Ethernet-кадр передается по сети Ethernet.

Короче говоря, если с помощью ARP-таблицы не удается сразу осуществить преобразование адресов, то IP-пакет ставится в очередь, а необходимая для преобразования информация получается с помощью запросов и ответов протокола ARP, после чего IP-пакет передается по назначению.

Если в сети нет машины с искомым IP-адресом, то ARP-ответа не будет и не будет записи в ARP-таблице. Протокол IP будет уничтожать IP-пакеты, направляемые по этому адресу. Протоколы верхнего уровня не могут отличить случай повреждения сети Ethernet от случая отсутствия машины с искомым IP-адресом.

Некоторые реализации IP и ARP не ставят в очередь IP-пакеты на то время, пока они ждут ARP-ответов. Вместо этого IP-пакет просто уничтожается, а его восстановление возлагается на модуль TCP или прикладной процесс, работающий через UDP. Такое восстановление выполняется с помощью таймаутов и повторных передач. Повторная передача сообщения проходит успешно, так как первая попытка уже вызвала заполнение ARP-таблицы.

Следует отметить, что каждая машина имеет отдельную ARP-таблицу для каждого своего сетевого интерфейса.


Основы TCP/IP

Термин "TCP/IP" обычно обозначает все, что связано с протоколами TCP и IP. Он охватывает целое семейство протоколов, прикладные программы и даже саму сеть. В состав семейства входят протоколы UDP, ARP, ICMP, TELNET, FTP и многие другие. TCP/IP - это технология межсетевого взаимодействия, технология internet. Сеть, которая использует технологию internet, называется "internet". Если речь идет о глобальной сети, объединяющей множество сетей с технологией internet, то ее называют Internet.

Модуль IP создает единую логическую сеть

Архитектура протоколов TCP/IP предназначена для объединенной сети, состоящей из соединенных друг с другом шлюзами отдельных разнородных пакетных подсетей, к которым подключаются разнородные машины. Каждая из подсетей работает в соответствии со своими специфическими требованиями и имеет свою природу средств связи. Однако предполагается, что каждая подсеть может принять пакет информации (данные с соответствующим сетевым заголовком) и доставить его по указанному адресу в этой конкретной подсети. Не требуется, чтобы подсеть гарантировала обязательную доставку пакетов и имела надежный сквозной протокол. Таким образом, две машины, подключенные к одной подсети могут обмениваться пакетами.

Когда необходимо передать пакет между машинами, подключенными к разным подсетям, то машина-отправитель посылает пакет в соответствующий шлюз (шлюз подключен к подсети также как обычный узел). Оттуда пакет направляется по определенному маршруту через систему шлюзов и подсетей, пока не достигнет шлюза, подключенного к той же подсети, что и машина-получатель; там пакет направляется к получателю. Объединенная сеть обеспечивает датаграммный сервис.

Проблема доставки пакетов в такой системе решается путем реализации во всех узлах и шлюзах межсетевого протокола IP. Межсетевой уровень является по существу базовым элементом во всей архитектуре протоколов, обеспечивая возможность стандартизации протоколов верхних уровней.

Структура связей протокольных модулей

Логическая структура сетевого программного обеспечения, реализующего протоколы семейства TCP/IP в каждом узле сети internet, изображена на рисунке. Прямоугольники обозначают обработку данных, а линии, соединяющие прямоугольники, - пути передачи данных. Горизонтальная линия внизу рисунка обозначает кабель сети Ethernet, которая используется в качестве примера физической среды; "o" - это трансивер. Знак "*" - обозначает

Рис.1. Структура протокольных модулей в узле сети TCP/IP
IP-адрес, а "@" - адрес узла в сети Ethernet (Ethernet-адрес). Понимание этой логической структуры является основой для понимания всей технологии internet. В дальнейшем мы будем часто ссылаться на эту схему.

Терминология

Введем ряд базовых терминов, которые мы будем использовать в дальнейшем.

Драйвер - это программа, непосредственно взаимодействующая с сетевым адаптером. Модуль - это программа, взаимодействующая с драйвером, сетевыми прикладными программами или другими модулями. Драйвер сетевого адаптера и, возможно, другие модули, специфичные для физической сети передачи данных, предоставляют сетевой интерфейс для протокольных модулей семейства TCP/IP.

Название блока данных, передаваемого по сети, зависит от того, на каком уровне стека протоколов он находится. Блок данных, с которым имеет дело сетевой интерфейс, называется кадром; если блок данных находится между сетевым интерфейсом и модулем IP, то он называется IP-пакетом; если он - между модулем IP и модулем UDP, то - UDP-датаграммой; если между модулем IP и модулем TCP, то - TCP-сегментом (или транспортным сообщением); наконец, если блок данных находится на уровне сетевых прикладных процессов, то он называется прикладным сообщением.

Эти определения, конечно, несовершенны и неполны. К тому же они меняются от публикации к публикации. Более подробные определения можно найти в RFC-1122, раздел 1.3.3.

Потоки данных

Рассмотрим потоки данных, проходящие через стек протоколов, изображенный на рис.1. В случае использования протокола TCP (Transmission Control Protocol - протокол управления передачей), данные передаются между прикладным процессом и модулем TCP. Типичным прикладным процессом, использующим протокол TCP, является модуль FTP (File Transfer Protocol протокол передачи файлов). Стек протоколов в этом случае будет FTP/TCP/IP/ENET. При использовании протокола UDP (User Datagram Protocol - протокол пользовательских датаграмм), данные передаются между прикладным процессом и модулем UDP. Например, SNMP (Simple Network Management Protocol - простой протокол управления сетью) пользуется транспортными услугами UDP. Его стек протоколов выглядит так: SNMP/UDP/IP/ENET.

Модули TCP, UDP и драйвер Ethernet являются мультиплексорами n x 1. Действуя как мультиплексоры, они переключают несколько входов на один выход. Они также являются демультиплексорами 1 x n. Как демультиплексоры, они переключают один вход на один из многих выходов в соответствии с полем типа в заголовке протокольного блока данных (рис.2).

Когда Ethernet-кадр попадает в драйвер сетевого интерфейса Ethernet, он может быть направлен либо в модуль ARP (Address Resolution Protocol адресный протокол), либо в модуль IP (Internet Protocol - межсетевой протокол). На то, куда должен быть направлен Ethernet-кадр, указывает значение поля типа в заголовке кадра.

Если IP-пакет попадает в модуль IP, то содержащиеся в нем данные могут быть переданы либо модулю TCP, либо UDP, что определяется полем "протокол" в заголовке IP-пакета.

Если UDP-датаграмма попадает в модуль UDP, то на основании значения поля "порт" в заголовке датаграммы определяется прикладная программа, которой должно быть передано прикладное сообщение. Если TCP-сообщение попадает в модуль TCP, то выбор прикладной программы, которой должно быть передано сообщение, осуществляется на основе значения поля "порт" в заголовке TCP-сообщения.

Мультиплексирование данных в обратную сторону осуществляется довольно просто, так как из каждого модуля существует только один путь вниз. Каждый протокольный модуль добавляет к пакету свой заголовок, на основании которого машина, принявшая пакет, выполняет демультиплексирование.

Рис.2. Мультиплексор n x 1 и демультиплексор 1 x n.
Данные от прикладного процесса проходят через модули TCP или UDP, после чего попадают в модуль IP и оттуда - на уровень сетевого интерфейса.

Хотя технология internet поддерживает много различных сред передачи данных, здесь мы будем предполагать использование Ethernet, так как именно эта среда чаще всего служит физической основой для IP-сети. Машина на рис.1 имеет одну точку соединения с Ethernet. Шестибайтный Ethernet-адрес является уникальным для каждого сетевого адаптера и распознается драйвером.

Машина имеет также четырехбайтный IP-адрес. Этот адрес обозначает точку доступа к сети на интерфейсе модуля IP с драйвером. IP-адрес должен быть уникальным в пределах всей сети Internet.

Работающая машина всегда знает свой IP-адрес и Ethernet-адрес.

Работа с несколькими сетевыми интерфейсами

Машина может быть подключена одновременно к нескольким средам передачи данных. На рис.3 показана машина с двумя сетевыми интерфейсами Ethernet. Заметим, что она имеет 2 Ethernet-адреса и 2 IP-адреса.

Из представленной схемы видно, что для машин с несколькими сетевыми интерфейсами модуль IP выполняет функции мультиплексора n x m и демультиплексора m x n (рис.4).

Рис.3. Узел сети TCP/IP с двумя сетевыми интерфейсами.

Рис.4. Мультиплексор n x m и демультиплексор m x n .
Таким образом, он осуществляет мультиплексирование входных и выходных данных в обоих направлениях. Модуль IP в данном случае сложнее, чем в первом примере, так как может передавать данные между сетями. Данные могут поступать через любой сетевой интерфейс и быть ретранслированы через любой другой сетевой интерфейс. Процесс передачи пакета в другую сеть называется ретрансляцией IP-пакета. Машина, выполняющая ретрансляцию, называется шлюзом. [1]

Как показано на рис.5, ретранслируемый пакет не передается модулям TCP или UDP. Некоторые шлюзы вообще могут не иметь модулей TCP и UDP.


Ethernet

В этом разделе мы кратко рассмотрим технологию Ethernet.

Кадр Ethernet содержит адрес назначения, адрес источника, поле типа и данные. Размер адреса в Ethernet - 6 байт. Каждый сетевой адаптер имеет свой Ethernet-адрес. Адаптер контролирует обмен информацией,
Рис.5. Пример межсетевой ретрансляции пакета модулем IP.

В документации по TCP/IP термины шлюз (gateway) и IPмаршрутизатор (IP-router) часто используются как синонимы. Мы сочли возможным использовать более распространенный термин "шлюз".

происходящий в сети, и принимает адресованные ему Ethernet-кадры, а также Ethernet-кадры с адресом "FF:FF:FF:FF:FF:FF" (в 16-ричной системе), который обозначает "всем", и используется при широковещательной передаче.

Ethernet реализует метод МДКН/ОС (множественный доступ с контролем несущей и обнаружением столкновений). Метод МДКН/ОС предполагает, что все устройства взаимодействуют в одной среде, в каждый момент времени может передавать только одно устройство, а принимать могут все одновременно. Если два устройства пытаются передавать одновременно, то происходит столкновение передач, и оба устройства после случайного (краткого) периода ожидания пытаются вновь выполнить передачу.

Аналогия с разговором

Хорошей аналогией взаимодействиям в среде Ethernet может служить разговор группы вежливых людей в небольшой темной комнате. При этом аналогией электрическим сигналам в коаксиальном кабеле служат звуковые волны в комнате.

Каждый человек слышит речь других людей (контроль несущей). Все люди в комнате имеют одинаковые возможности вести разговор (множественный доступ), но никто не говорит слишком долго, так как все вежливы. Если человек будет невежлив, то его попросят выйти (т.е. удалят из сети). Все молчат, пока кто-то говорит. Если два человека начинают говорить одновременно, то они сразу обнаруживают это, поскольку слышат друг друга (обнаружение столкновений). В этом случае они замолкают и ждут некоторое время, после чего один из них вновь начинает разговор. Другие люди слышат, что ведется разговор, и ждут, пока он кончится, а затем могут начать говорить сами. Каждый человек имеет собственное имя (аналог уникального Ethernet-адреса). Каждый раз, когда кто-нибудь начинает говорить, он называет по имени того, к кому обращается, и свое имя, например, "Слушай Петя, это Андрей, ... ля-ля-ля ..." Если кто-то хочет обратиться ко всем, то он говорит: "Слушайте все, это Андрей, ... ля-ля-ля ..." (широковещательная передача).


Взаимозависимость протоколов семейства TCP/IP

Ниже на рисунке представлена схема взаимосвязей между протоколами семейства TCP/IP.

Структура взаимосвязей протоколов семейства TCP/IP
Подробное описание протоколов можно найти в RFC, тематический каталог которых приведен в Приложении 1, а состояние стандартов отражено в Приложении 2.


Семейство протоколов TCP/IP

  • Введение
  • Основы TCP/IP
    • Модуль IP создает единую логическую сеть
    • Структура связей протокольных модулей
    • Терминология
    • Потоки данных
    • Работа с несколькими сетевыми интерфейсами
  • Ethernet
    • Аналогия с разговором
  • Протокол ARP
    • ARP-таблица для преобразования адресов
    • Порядок преобразования адресов
    • Запросы и ответы протокола ARP
    • Продолжение преобразования адресов
  • Межсетевой протокол IP
    • Прямая маршрутизация
    • Косвенная маршрутизация
    • Правила маршрутизации в модуле IP
    • IP-адрес
    • Выбор адреса
    • Подсети
    • Как назначать номера сетей и подсетей
    • Имена
    • IP-таблица маршрутов
    • Подробности прямой маршрутизации
    • Порядок прямой маршрутизации
    • Подробности косвенной маршрутизации
    • Порядок косвенной маршрутизации
  • Установка маршрутов
    • Фиксированные маршруты
    • Перенаправление маршрутов
    • Слежение за маршрутизацией
    • Протокол ARP с представителем
  • Протокол UDP
    • Порты
    • Контрольное суммирование
  • Протокол TCP
  • Протоколы прикладного уровня
    • Протокол TELNET
    • Протокол FTP
    • Протокол SMTP
    • r-команды
    • NFS
    • Протокол SNMP
    • X-Window
  • Взаимозависимость протоколов семейства TCP/IP
  • Приложение 1. Путеводитель по RFC
  • Приложение 2. Стандарты семейства протоколов TCP/IP


Введение

Семейство протоколов TCP/IP широко применяется во всем мире для объединения компьютеров в сеть Internet. Единая сеть Internet состоит из множества сетей различной физической природы, от локальных сетей типа Ethernet и Token Ring, до глобальных сетей типа NSFNET. Основное внимание в книге уделяется принципам организации межсетевого взаимодействия. Многие технические детали, исторические вопросы опущены. Более подробную информацию о протоколах TCP/IP можно найти в RFC (Requests For Comments) - специальных документах, выпускаемых Сетевым Информационным Центром (Network Information Center - NIC). Приложение 1 содержит путеводитель по RFC, а приложение 2 отражает положение дел в области стандартизации протоколов семейства TCP/IP на начало 1991 года.

В книге приводятся примеры, основанные на реализации TCP/IP в ОС UNIX. Однако основные положения применимы ко всем реализациям TCP/IP.

Надеюсь, что эта книга будет полезна тем, кто профессионально работает или собирается начать работать в среде TCP/IP: системным администраторам, системным программистам и менеджерам сети.


Межсетевой протокол IP

Модуль IP является базовым элементом технологии internet, а центральной частью IP является его таблица маршрутов. Протокол IP использует эту таблицу при принятии всех решений о маршрутизации IP-пакетов. Содержание таблицы маршрутов определяется администратором сети. Ошибки при установке маршрутов могут заблокировать передачи.

Чтобы понять технику межсетевого взаимодействия, нужно понять то, как используется таблица маршрутов. Это понимание необходимо для успешного администрирования и сопровождения IP-сетей.

Прямая маршрутизация

На рисунке показана небольшая IP-сеть, состоящая из 3 машин: A, B и C. Каждая машина имеет такой же стек протоколов TCP/IP как на рис.1. Каждый сетевой адаптер этих машин имеет свой Ethernet-адрес. Менеджер сети должен присвоить машинам уникальные IP-адреса.

Рис.6. Простая IP-сеть
Когда A посылает IP-пакет B, то заголовок IP-пакета содержит в поле отправителя IP-адрес узла A, а заголовок Ethernet-кадра содержит в поле отправителя Ethernet-адрес A. Кроме этого, IP-заголовок содержит в поле получателя IP-адрес узла B, а Ethernet-заголовок содержит в поле получателя Ethernet-адрес B.

адрес | отправитель | получатель
IP-заголовок Ethernet-заголовок | A A | B B

Табл.5. Адреса в Ethernet-кадре, передающем IP-пакет от A к B. В этом простом примере протокол IP является излишеством, которое мало что добавляет к услугам, предоставляемым сетью Ethernet. Однако протокол IP требует дополнительных расходов на создание, передачу и обработку IP-заголовка. Когда в машине B модуль IP получает IP-пакет от машины A, он сопоставляет IP-адрес места назначения со своим и, если адреса совпадают, то передает датаграмму протоколу верхнего уровня.

В данном случае при взаимодействии A с B используется прямая маршрутизация.

Косвенная маршрутизация

На рисунке представлена более реалистичная картина сети internet. В данном случае сеть internet состоит из трех сетей Ethernet, на базе которых работают три IP-сети, объединенные шлюзом D. Каждая IP-сеть включает четыре машины; каждая машина имеет свои собственные IP- и Ethernet адреса.

Рис.7. Сеть internet, состоящая из трех IP-сетей
За исключением D все машины имеют стек протоколов, аналогичный показанному на рисунке. Шлюз D соединяет все три сети и, следовательно, имеет три IP-адреса и три Ethernet-адреса. Машина D имеет стек протоколов TCP/IP, похожий на тот, что показан на рис.3, но вместо двух модулей ARP и двух драйверов, он содержит три модуля ARP и три драйвера Ethernet. Обратим внимание на то, что машина D имеет только один модуль IP.

Менеджер сети присваивает каждой сети Ethernet уникальный номер, называемый IP-номером сети. На рис.7 IP-номера не показаны, вместо них используются имена сетей.

Когда машина A посылает IP-пакет машине B, то процесс передачи идет в пределах одной сети. При всех взаимодействиях между машинами, подключенными к одной IP-сети, используется прямая маршрутизация, обсуждавшаяся в предыдущем примере.

Когда машина D взаимодействует с машиной A, то это прямое взаимодействие. Когда машина D взаимодействует с машиной E, то это прямое взаимодействие. Когда машина D взаимодействует с машиной H, то это прямое взаимодействие. Это так, поскольку каждая пара этих машин принадлежит одной IP-сети.

Однако, когда машина A взаимодействует с машинами, включенными в другую IP-сеть, то взаимодействие уже не будет прямым. Машина A должна использовать шлюз D для ретрансляции IP-пакетов в другую IP-сеть. Такое взаимодействие называется "косвенным".

Маршрутизация IP-пакетов выполняется модулями IP и является прозрачной для модулей TCP, UDP и прикладных процессов.

Если машина A посылает машине E IP-пакет, то IP-адрес и Ethernet-адрес отправителя соответствуют адресам A. IP-адрес места назначения является адресом E, но поскольку модуль IP в A посылает IP-пакет через D, Ethernet-адрес места назначения является адресом D.

адрес | отправитель | получатель
IP-заголовок Ethernet-заголовок | A A | E D

Табл.6. Адреса в Ethernet-кадре, содержащем IP-пакет от A к E (до шлюза D). Модуль IP в машине D получает IP-пакет и проверяет IP-адрес места назначения. Определив, что это не его IP-адрес, шлюз D посылает этот IP-пакет прямо к E.

адрес | отправитель | получатель
IP-заголовок Ethernet-заголовок | A D | E E

Табл.7. Адреса в Ethernet-кадре, содержащем IP-пакет от A к E (после шлюз D) Итак, при прямой маршрутизации IP- и Ethernet-адреса отправителя соответствуют адресам того узла, который послал IP-пакет, а IP- и Ethernet-адреса места назначения соответствуют адресам получателя. При косвенной маршрутизации IP- и Ethernet-адреса не образуют таких пар.

В данном примере сеть internet является очень простой. Реальные сети могут быть гораздо сложнее, так как могут содержать несколько шлюзов и несколько типов физических сред передачи. В приведенном примере несколько сетей Ethernet объединяются шлюзом для того, чтобы локализовать широковещательный трафик в каждой сети.

Правила маршрутизации в модуле IP

Выше мы показали, что происходит при передаче сообщений, а теперь рассмотрим правила или алгоритм маршрутизации.

Для отправляемых IP-пакетов, поступающих от модулей верхнего уровня, модуль IP должен определить способ доставки - прямой или косвенный - и выбрать сетевой интерфейс. Этот выбор делается на основании результатов поиска в таблице маршрутов.

Для принимаемых IP-пакетов, поступающих от сетевых драйверов, модуль IP должен решить, нужно ли ретранслировать IP-пакет по другой сети или передать его на верхний уровень. Если модуль IP решит, что IP-пакет должен быть ретранслирован, то дальнейшая работа с ним осуществляется также, как с отправляемыми IP-пакетами.

Входящий IP-пакет никогда не ретранслируется через тот же сетевой интерфейс, через который он был принят.

Решение о маршрутизации принимается до того, как IP-пакет передается сетевому драйверу, и до того, как происходит обращение к ARP-таблице.

IP-адрес

Менеджер сети присваивает IP-адреса машинам в соответствии с тем, к каким IP-сетям они подключены. Старшие биты 4-х байтного IP-адреса определяют номер IP-сети. Оставшаяся часть IP-адреса - номер узла (хостномер). Для машины из табл.1 с IP-адресом 223.1.2.1 сетевой номер равен 223.1.2, а хост-номер - 1. Напомним, что IP-адрес узла идентифицирует точку доступа модуля IP к сетевому интерфейсу, а не всю машину.

Существуют 5 классов IP-адресов, отличающиеся количеством бит в сетевом номере и хост-номере. Класс адреса определяется значением его первого октета.

В табл.8 приведено соответствие классов адресов значениям первого октета и указано количество возможных IP-адресов каждого класса.

Рис.8. Структура IP-адресов

Класс | Диапазон значений первого октета | Возможное кол-во сетей | Возможное кол-во узлов
A B C D E | 1 - 126 128-191 192-223 224-239 240-247 | 126 16382 2097150 - - | 16777214 65534 254 2**28 2**27

Табл.8. Характеристики классов адресов Адреса класса A предназначены для использования в больших сетях общего пользования. Они допускают большое количество номеров узлов. Адреса класса B используются в сетях среднего размера, например, сетях университетов и крупных компаний. Адреса класса C используются в сетях с небольшим числом компьютеров. Адреса класса D используются при обращениях к группам машин, а адреса класса E зарезервированы на будущее.

Некоторые IP-адреса являются выделенными и трактуются по-особому.

Рис.9. Выделенные IP-адреса
Как показано на рис.9, в выделенных IP-адресах все нули соответствуют либо данному узлу, либо данной IP-сети, а IP-адреса, состоящие из всех единиц, используются при широковещательных передачах. Для ссылок на всю IP-сеть в целом используется IP-адрес с нулевым номером узла. Особый смысл имеет IP-адрес, первый октет которого равен 127. Он используется для тестирования программ и взаимодействия процессов в пределах одной машины. Когда программа посылает данные по IP-адресу 127.0.0.1, то образуется как бы "петля". Данные не передаются по сети, а возвращаются модулям верхнего уровня, как только что принятые. Поэтому в IP-сети запрещается присваивать машинам IP-адреса, начинающиеся со 127.

Выбор адреса

Прежде чем вы начнете использовать сеть с TCP/IP, вы должны получить один или несколько официальных сетевых номеров. Выделением номеров (как и многими другими вопросами) занимается DDN Network Information Center (NIC)

SRI International, Room EJ210, 333 Ravenswood Avenue, Menlo Park, California 94025, USA. Тел. 1-800-235-3155. E-mail: NIC@NIC.DDN.MIL

Выделение номеров производится бесплатно и занимает около недели. Вы можете получить сетевой номер вне зависимости от того, для чего предназначена ваша сеть. Даже если ваша сеть не имеет связи с объединенной сетью Internet, получение уникального номера желательно, так как в этом случае есть гарантия, что в будущем при включении в Internet или при подключении к сети другой организации не возникнет конфликта адресов.

Одно из важнейших решений, которое необходимо принять при установке сети, заключается в выборе способа присвоения IP-адресов вашим машинам. Этот выбор должен учитывать перспективу роста сети. Иначе в дальнейшем вам придется менять адреса. Когда к сети подключено несколько сотен машин, изменение адресов становится почти невозможным.

Организации, имеющие небольшие сети с числом узлов до 126, должны запрашивать сетевые номера класса C. Организации с большим числом машин могут получить несколько номеров класса C или номер класса B. Удобным средством структуризации сетей в рамках одной организации являются подсети.

Подсети

Адресное пространство сети internet может быть разделено на непересекающиеся подпространства - "подсети", с каждой из которых можно работать как с обычной сетью TCP/IP. Таким образом единая IP-сеть организации может строиться как объединение подсетей. Как правило, подсеть соответствует одной физической сети, например, одной сети Ethernet.

Конечно, использование подсетей необязательно. Можно просто назначить для каждой физической сети свой сетевой номер, например, номер класса C. Однако такое решение имеет два недостатка. Первый, и менее существенный, заключается в пустой трате сетевых номеров. Более серьезный недостаток состоит в том, что если ваша организация имеет несколько сетевых номеров, то машины вне ее должны поддерживать записи о маршрутах доступа к каждой из этих IP-сетей. Таким образом, структура IP-сети организации становится видимой для всего мира. При каких-либо изменениях в IP-сети информация о них должна быть учтена в каждой из машин, поддерживающих маршруты доступа к данной IP-сети.

Подсети позволяют избежать этих недостатков. Ваша организация должна получить один сетевой номер, например, номер класса B. Стандарты TCP/IP определяют структуру IP-адресов. Для IP-адресов класса B первые два октета являются номером сети. Оставшаяся часть IP-адреса может использоваться как угодно. Например, вы можете решить, что третий октет будет определять номер подсети, а четвертый октет - номер узла в ней. Вы должны описать конфигурацию подсетей в файлах, определяющих маршрутизацию IP-пакетов. Это описание является локальным для вашей организации и не видно вне ее. Все машины вне вашей организации видят одну большую IPсеть. Следовательно, они должны поддерживать только маршруты доступа к шлюзам, соединяющим вашу IP-сеть с остальным миром. Изменения, происходящие в IP-сети организации, не видны вне ее. Вы легко можете добавить новую подсеть, новый шлюз и т.п.

Как назначать номера сетей и подсетей

После того, как решено использовать подсети или множество IP-сетей, вы должны решить, как назначать им номера. Обычно это довольно просто. Каждой физической сети, например, Ethernet или Token Ring, назначается отдельный номер подсети или номер сети. В некоторых случаях имеет смысл назначать одной физической сети несколько подсетевых номеров. Например, предположим, что имеется сеть Ethernet, охватывающая три здания. Ясно, что при увеличении числа машин, подключенных к этой сети, придется ее разделить на несколько отдельных сетей Ethernet. Для того, чтобы избежать необходимости менять IP-адреса, когда это произойдет, можно заранее выделить для этой сети три подсетевых номера - по одному на здание. (Это полезно и в том случае, когда не планируется физическое деление сети. Просто такая адресация позволяет сразу определить, где находится та или иная машина.) Однако прежде, чем выделять три различных подсетевых номера одной физической сети, тщательно проверьте, что все ваши программы способны работать в такой среде.

Вы также должны выбрать "маску подсети". Она используется сетевым программным обеспечением для выделения номера подсети из IP-адресов. Биты IP-адреса, определяющие номер IP-сети, в маске подсети должны быть равны 1, а биты, определяющие номер узла, в маске подсети должны быть равны 0. Как уже отмечалось, стандарты TCP/IP определяют количество октетов, задающих номер сети. Часто в IP-адресах класса B третий октет используется для задания номера подсети. Это позволяет иметь 256 подсетей, в каждой из которых может быть до 254 узлов. Маска подсети в такой системе равна 255.255.255.0. Но, если в вашей сети должно быть больше подсетей, а в каждой подсети не будет при этом более 60 узлов, то можно использовать маску 255.255.255.192. Это позволяет иметь 1024 подсети и до 62 узлов в каждой. (Напомним, что номера узлов 0 и "все единицы" используются особым образом.)

Обычно маска подсети указывается в файле стартовой конфигурации сетевого программного обеспечения. Протоколы TCP/IP позволяют также запрашивать эту информацию по сети.

Имена

Людям удобнее называть машины по именам, а не числами. Например, у машины по имени alpha может быть IP-адрес 223.1.2.1. В маленьких сетях информация о соответствии имен IP-адресам хранится в файлах "hosts" на каждом узле. Конечно, название файла зависит от конкретной реализации. В больших сетях эта информация хранится на сервере и доступна по сети. Несколько строк из файла "hosts" могут выглядеть примерно так:

               223.1.2.1      alpha
                       223.1.2.2      beta
                       223.1.2.3      gamma
                       223.1.2.4      delta
                       223.1.3.2      epsilon
                       223.1.4.2      iota

В первом столбце - IP-адрес, во втором - название машины.

В большинстве случаев файлы "hosts" могут быть одинаковы на всех узлах. Заметим, что о узле delta в этом файле есть всего одна запись, хотя он имеет три IP-адреса (рис.11). Узел delta доступен по любому из этих IP-адресов. Какой из них используется, не имеет значения. Когда узел delta получает IP-пакет и проверяет IP-адрес места назначения, то он опознает любой из трех своих IP-адресов.

IP-сети также могут иметь имена. Если у вас есть три IP-сети, то файл "networks" может выглядеть примерно так:

                     223.1.2        development
                     223.1.3        accounting
                     223.1.4        factory

В первой колонке - сетевой номер, во второй - имя сети.

В данном примере alpha является узлом номер 1 в сети development, beta является узлом номер 2 в сети development и т.д.

Показанный выше файл hosts удовлетворяет потребности пользователей, но для управления сетью internet удобнее иметь названия всех сетевых интерфейсов. Менеджер сети, возможно, заменит строку, относящуюся к delta:

                223.1.2.4      devnetrouter     delta
                223.1.3.1      accnetrouter
                223.1.4.1      facnetrouter

Эти три строки файла hosts задают каждому IP-адресу узла delta символьные имена. Фактически, первый IP-адрес имеет два имени: "devnetrouter" и "delta", которые являются синонимами. На практике имя "delta" используется как общеупотребительное имя машины, а остальные три имени - для администрирования сети.

Файлы hosts и networks используются командами администрирования и прикладными программами. Они не нужны собственно для работы сети internet, но облегчают ее использование.

IP-таблица маршрутов

Как модуль IP узнает, какой именно сетевой интерфейс нужно использовать для отправления IP-пакета? Модуль IP осуществляет поиск в таблице маршрутов. Ключом поиска служит номер IP-сети, выделенный из IP-адреса места назначения IP-пакета.

Таблица маршрутов содержит по одной строке для каждого маршрута. Основными столбцами таблицы маршрутов являются номер сети, флаг прямой или косвенной маршрутизации, IP-адрес шлюза и номер сетевого интерфейса. Эта таблица используется модулем IP при обработке каждого отправляемого IP-пакета.

В большинстве систем таблица маршрутов может быть изменена с помощью команды "route". Содержание таблицы маршрутов определяется менеджером сети, поскольку менеджер сети присваивает машинам IP-адреса.

Подробности прямой маршрутизации

Рассмотрим более подробно, как происходит маршрутизация в одной физической сети.

Рис.10. Одна физическая сеть
Таблица маршрутов в узле alpha выглядит так:

сеть | флаг вида маршрутизации | шлюз | номер интерфейса
development | прямая | <пусто> | 1

Табл.9. Пример таблицы маршрутов В данном простом примере все узлы сети имеют одинаковые таблицы маршрутов.

Для сравнения ниже представлена та же таблица, но вместо названия сети указан ее номер.

сеть | флаг вида маршрутизации | шлюз | номер интерфейса
223.1.2 | прямая | <пусто> | 1

Табл.10. Пример таблицы маршрутов с номерами сетей.

Порядок прямой маршрутизации

Узел alpha посылает IP-пакет узлу beta. Этот пакет находится в модуле IP узла alpha, и IP-адрес места назначения равен IP-адресу beta (223.1.2.2). Модуль IP с помощью маски подсети выделяет номер сети из IP-адреса и ищет соответствующую ему строку в таблице маршрутов. В данном случае подходит первая строка.

Остальная информация в найденной строке указывает на то, что машины этой сети доступны напрямую через интерфейс номер 1. С помощью ARP-таблицы выполняется преобразование IP-адреса в соответствующий Ethernet-адрес, и через интерфейс 1 Ethernet-кадр посылается узлу beta.

Если прикладная программа пытается послать данные по IP-адресу, который не принадлежит сети development, то модуль IP не сможет найти соответствующую запись в таблице маршрутов. В этом случае модуль IP отбрасывает IP-пакет. Некоторые реализации протокола возвращают сообщение об ошибке "Сеть не доступна".

Подробности косвенной маршрутизации

Теперь рассмотрим более сложный порядок маршрутизации в IP-сети, изображенной на рис.11.

Таблица маршрутов в узле alpha выглядит так:

сеть | флаг вида маршрутизации | шлюз | номер интерфейса
development | прямая | <пусто> | 1
accounting | косвенная | devnetrouter | 1
factory | косвенная | devnetrouter | 1

Табл.11. Таблица маршрутов в узле alpha.
Рис.11. Подробная схема трех сетей
Та же таблица с IP-адресами вместо названий.

сеть | флаг вида маршрутизации | шлюз | номер интерфейса
223.1.2 | прямая | <пусто> | 1
223.1.3 | косвенная | 223.1.2.4 | 1
223.1.4 | косвенная | 223.1.2.4 | 1

Табл.12. Таблица маршрутов в узле alpha (с номерами) В столбце "шлюз" таблицы маршрутов узла alpha указывается IP-адрес точки соединения узла delta с сетью development.

Порядок косвенной маршрутизации

Узел alpha посылает IP-пакет узлу epsilon. Этот пакет находится в модуле IP узла alpha, и IP-адрес места назначения равен IP-адресу узла epsilon (223.1.3.2). Модуль IP выделяет сетевой номер из IP-адреса (223.1.3) и ищет соответствующую ему строку в таблице маршрутов. Соответствие находится во второй строке.

Запись в этой строке указывает на то, что машины требуемой сети доступны через шлюз devnetrouter. Модуль IP в узле alpha осуществляет поиск в ARP-таблице, с помощью которого определяет Ethernet-адрес, соответствующий IP-адресу devnetrouter. Затем IP-пакет, содержащий IP-адрес места назначения epsilon, посылается через интерфейс 1 шлюзу devnetrouter.

IP-пакет принимается сетевым интерфейсом в узле delta и передается модулю IP. Проверяется IP-адрес места назначения, и, поскольку он не соответствует ни одному из собственных IP-адресов delta, шлюз решает ретранслировать IP-пакет.

Модуль IP в узле delta выделяет сетевой номер из IP-адреса места назначения IP-пакета (223.1.3) и ищет соответствующую запись в таблице маршрутов. Таблица маршрутов в узле delta выглядит так:

сеть | флаг вида маршрутизации | шлюз | номер интерфейса
development | прямая | <пусто> | 1
accounting | прямая | <пусто> | 2
factory | прямая | <пусто> | 3

Табл.13. Таблица маршрутов в узле delta Та же таблица с IP-адресами вместо названий.

сеть | флаг вида маршрутизации | шлюз | номер интерфейса
223.1.2 | прямая | <пусто> | 1
223.1.3 | прямая | <пусто> | 2
223.1.4 | прямая | <пусто> | 3

Табл.14. Таблица маршрутов в узле delta (с номерами) Соответствие находится во второй строке. Теперь модуль IP напрямую посылает IP-пакет узлу epsilon через интерфейс номер 3. Пакет содержит IP- и Ethernet-адреса места назначения равные epsilon.

Узел epsilon принимает IP-пакет, и его модуль IP проверяет IP-адрес места назначения. Он соответствует IP-адресу epsilon, поэтому содержащееся в IP-пакете сообщение передается протокольному модулю верхнего уровня.


Установка маршрутов

До сих пор мы рассматривали то, как используется таблица маршрутов для маршрутизации IP-пакетов. Но откуда берется информация в самой таблице маршрутов? В данном разделе мы рассмотрим методы, позволяющие поддерживать корректность таблиц маршрутов.

Фиксированные маршруты

Простейший способ проведения маршрутизации состоит в установке маршрутов при запуске системы с помощью специальных команд. Этот метод можно применять в относительно маленьких IP-сетях, в особенности, если их конфигурации не часто меняются.

На практике большинство машин автоматически формирует таблицы маршрутов. Например, UNIX добавляет записи о IP-сетях, к которым есть непосредственный доступ. Стартовый файл может содержать команды

ifconfig  ie0  128.6.4.4   netmask  255.255.255.0
ifconfig  ie1  128.6.5.35  netmask  255.255.255.0

Они показывают, что существуют
два сетевых интерфейса, и
устанавливают их IP-адреса. Система
может автоматически создать две
записи в таблице маршрутов:

сеть | флаг вида маршрутизации | шлюз | интерфейс
128.6.4 | прямая | <пусто> | ie0
128.6.5 | прямая | <пусто> | ie1

Табл.15.
Автоматически создаваемые записи Эти
записи определяют, что IP-пакеты для
локальных подсетей 128.6.4 и 128.6.5
должны посылаться через указанные
интерфейсы.

В стартовом файле могут
быть команды, определяющие
маршруты доступа к другим IP-сетям.
Например,

route  add  128.6.2.0  128.6.4.1   1
route  add  128.6.6.0  128.6.5.35  0

Эти команды показывают,
что в таблицу маршрутов должны быть
добавлены две записи. Первый адрес
в командах является IP-адресом сети,
второй адрес указывает шлюз,
который должен использоваться для
доступа к данной IPсети, а третий
параметр является метрикой.
Метрика показывает, на каком
"расстоянии" находится
описываемая IP-сеть. В данном случае
метрика это количество шлюзов на
пути между двумя IP-сетями. Маршруты
с метрикой 1 и более определяют
первый шлюз на пути к IP-сети.
Маршруты с метрикой 0 показывают,
что никакой шлюз не нужен - данный
маршрут задает дополнительный
сетевой номер локальной IP-сети.

Таким образом, команды,
приведенные в примере, говорят о
том, что для доступа к IP-сети 128.6.2
должен использоваться шлюз 128.6.4.1, а
IP-сеть 128.6.6 - это просто
дополнительный номер для
физической сети, подключенной к
интерфейсу 128.6.5.35.

сеть | флаг вида маршрутизации | шлюз | интерфейс
128.6.2 | косвенная | 128.6.4.1 | ie0
128.6.6 | прямая | <пусто> | ie1

Табл.16. Записи,
добавляемые в таблицу маршрутов Можно
определить маршрут по умолчанию,
который используется в тех случаях,
когда IP-адрес места назначения не
встречается в таблице маршрутов
явно. Обычно маршрут по умолчанию
указывает IP-адрес шлюза, который
имеет достаточно информации для
маршрутизации IP-пакетов со всеми
возможными адресами назначения.

Если ваша IP-сеть имеет
всего один шлюз, тогда все, что
нужно сделать, - это установить
единственную запись в таблице
маршрутов, указав этот шлюз как
маршрут по умолчанию. После этого
можно не заботиться о формировании
маршрутов в других узлах. (Конечно,
сам шлюз требует больше внимания.)

Следующие разделы
посвящены IP-сетям, где есть
несколько шлюзов.

Перенаправление
маршрутов

Большинство экспертов по
межсетевому взаимодействию
рекомендуют оставлять решение
проблем маршрутизации шлюзам.
Плохо иметь на каждой машине
большую таблицу маршрутов. Дело в
том, что при каких-либо изменениях в
IP-сети приходится менять
информацию во всех машинах.
Например, при отключении
какого-нибудь канала связи для
восстановления нормальной работы
нужно ждать, пока кто-то заметит это
изменение в конфигурации IPсети и
внесет исправления во все таблицы
маршрутов.

Простейший способ
поддержания адекватности
маршрутов заключается в том, что
изменение таблицы маршрутов каждой
машины выполняется по командам
только одного шлюза. Этот шлюз
должен быть установлен как маршрут
по умолчанию. (В ОС UNIX это делается
командой "route add default 128.6.4.27 1",
где 128.6.4.27 является IP-адресом шлюза.)
Как было описано выше, каждая
машина посылает IP-пакет шлюзу по
умолчанию в том случае, когда не
находит лучшего маршрута. Однако,
когда в IP-сети есть несколько
шлюзов, этот метод работает не так
хорошо. Кроме того, если таблица
маршрутов имеет только одну запись
о маршруте по умолчанию, то как
использовать другие шлюзы, если это
более выгодно? Ответ состоит в том,
что большинство шлюзов способны
выполнять "перенаправление" в
тех случаях, когда они получают
IP-пакеты, для которых существуют
более выгодные маршруты.
"Перенаправление" является
специальным типом сообщения
протокола ICMP (Internet Control Message Protocol -
протокол межсетевых управляющих
сообщений). Сообщение о
перенаправлении содержит
информацию, которую можно
интерпретировать так: "В будущем
для IP-адреса XXXX используйте шлюз YYYY,
а не меня". Корректные реализации
TCP/IP должны использовать сообщения
о перенаправлении для добавления
записей в таблицу маршрутов.
Предположим, таблица маршрутов в
начале выглядит следующим образом:

сеть | флаг вида маршрутизации | шлюз | интерфейс
127.0.0 | прямая | <пусто> | lo0
128.6.4 | прямая | <пусто> | pe0
default | косвенная | 128.6.4.27 | pe0

Табл.17. Таблица
маршрутов в начале работы Эта
таблица содержит запись о
локальной IP-сети 128.6.4 и маршрут по
умолчанию, указывающий шлюз 128.6.4.27.
Допустим, что существует шлюз
128.6.4.30, который является лучшим
путем доступа к IP-сети 128.6.7. Как им
воспользоваться? Предположим, что
нужно посылать IP-пакеты по IP-адресу
128.6.7.23. Первый IP-пакет пойдет на шлюз
по умолчанию, так как это
единственный подходящий маршрут,
описанный в таблице. Однако шлюз
128.6.4.27 знает, что существует лучший
маршрут, проходящий через шлюз
128.6.4.30. (Как он узнает об этом, мы
сейчас не рассматриваем.
Существует довольно простой метод
определения лучшего маршрута.) В
этом случае шлюз 128.6.4.27 возвращает
сообщение перенаправления, где
указывает, что IP-пакеты для узла
128.6.7.23 должны посылаться через шлюз
128.6.4.30. Модуль IP на
машине-отправителе должен добавить
запись в таблицу маршрутов:

сеть | флаг вида маршрутизации | шлюз | интерфейс
128.6.7.23 | косвенная | 128.6.4.30 | pe0

Табл.18. Новая
запись в таблице маршрутов Все
последующие IP-пакеты для узла 128.6.7.23
будут посланы прямо через
указанный шлюз.

До сих пор мы
рассматривали способы добавления
маршрутов в IP-таблицу, но не способы
их исключения. Что случится, если
шлюз будет выключен? Хотелось бы
иметь способ возврата к маршруту по
умолчанию после того, как
какой-либо маршрут разрушен.
Однако, если шлюз вышел из строя или
был выключен, то он уже не может
послать сообщение перенаправления.
Поэтому должен существовать метод
определения работоспособности
шлюзов, с которыми ваша машина
связана непосредственно. Лучший
способ обнаружения неработающих
шлюзов основан на выявлении
"плохих" маршрутов. Модуль TCP
поддерживает различные таймеры,
которые помогают ему определить
разрыв соединения. Когда случается
сбой, то можно пометить маршрут как
"плохой" и вернуться к
маршруту по умолчанию. Аналогичный
метод может использоваться при
обработке ошибок шлюза по
умолчанию. Если два шлюза отмечены
как шлюзы по умолчанию, то машина
может использовать их по очереди,
переключаясь между ними при
возникновении сбоев.

Слежение за
маршрутизацией

Заметим, что сообщения
перенаправления не могут
использоваться самими шлюзами.
Перенаправление - это просто способ
оповещения обычного узла о том, что
нужно использовать другой шлюз.
Сами шлюзы должны иметь полную
картину о положении дел в сети internet
и уметь вычислять оптимальные
маршруты доступа к каждой подсети.
Обычно они поддерживают эту
картину, обмениваясь информацией
между собой. Для этой цели
существуют несколько специальных
протоколов маршрутизации. Один из
способов, с помощью которого узлы
могут определять действующие
шлюзы, состоит в слежении за
обменом сообщениями между ними. Для
большинства протоколов
маршрутизации существует
программное обеспечение,
позволяющее обычным узлам
осуществлять такое слежение. При
этом на узлах поддерживается
полная картина положения дел в сети
internet точно также, как это делается в
шлюзах. Динамическая корректировка
таблицы маршрутов позволяет
посылать IP-пакеты по оптимальным
маршрутам.

Таким образом, слежение
за маршрутизацией в некотором
смысле "решает" проблему
поддержания корректности таблиц
маршрутов. Однако существуют
несколько причин, по которым этот
метод применять не рекомендуется.
Наиболее серьезной проблемой
является то, что протоколы
маршрутизации пока еще
подвергаются частым пересмотрам и
изменениям. Появляются новые
протоколы маршрутизации. Эти
изменения должны учитываться в
программном обеспечении всех
машин.

Несколько более
специальная проблема связана с
бездисковыми рабочими станциями.
По своей природе бездисковые
машины сильно зависят от сети и от
файл-серверов, с которых они
осуществляют загрузку программ, и
где располагается их область
своппинга. Исполнение программ,
следящих за широковещательными
передачами в сети, на бездисковых
машинах связано с большими
трудностями. Протоколы
маршрутизации построены в основном
на широковещательных передачах.
Например, все сетевые шлюзы могут
широковещательно передавать
содержание своих таблиц маршрутов
через каждые 30 секунд. Программы,
которые следят за такими
передачами, должны быть загружены
на бездисковые станции через сеть.
На достаточно занятой машине
программы, которые не используются
в течение нескольких секунд, обычно
отправляются в область своппинга.
Поэтому программы, следящие за
маршрутизацией, большую часть
времени находятся в своппинге.
Когда они вновь активизируются,
должна производиться подкачка из
своппинга. Как только посылается
широковещательное сообщение, все
машины активизируют программы,
следящие за маршрутизацией. Это
приводит к тому, что многие
бездисковые станции будут
выполнять подкачку из своппинга в
одно и тоже время. Поэтому в сети
возникнет временная перегрузка.
Таким образом, исполнение программ,
прослушивающих широковещательные
передачи, на бездисковых рабочих
станциях очень нежелательно.

Протокол ARP с
представителем

Протокол ARP с
представителем является
альтернативным методом,
позволяющим шлюзам принимать все
необходимые решения о
маршрутизации. Он применяется в
сетях с широковещательной
передачей, где для отображения
IP-адресов в сетевые адреса
используется протокол ARP или ему
подобный. Здесь мы вновь будем
предполагать, что имеем дело с
сетью Ethernet.

Во многом метод,
реализуемый протоколом ARP с
представителем, аналогичен
использованию маршрутов по
умолчанию и сообщений
перенаправления. Но протокол ARP с
представителем не затрагивает
таблиц маршрутов, все делается на
уровне адресов Ethernet. Протокол ARP с
представителем может
использоваться либо для
маршрутизации IP-пакетов ко всем
сетям, либо только в локальной сети,
либо в какой-то комбинации
подсетей. Проще всего
продемонстрировать его
использование при работе со всеми
адресами.

Чтобы использовать
протокол, нужно настроить узел так,
как будто все машины в мире
подключены непосредственно к вашей
локальной сети Ethernet. В ОС UNIX это
делается командой "route add default
128.6.4.2 0", где 128.6.4.2 - IP-адрес вашего
узла. Как уже отмечалось, метрика 0
говорит о том, что все IP-пакеты,
которым подходит данный маршрут,
должны посылаться напрямую по
локальной сети.

Когда нужно послать
IP-пакет узлу в локальной сети Ethernet,
ваша машина должна определить
Ethernet-адрес этого узла. Для этого она
использует ARP-таблицу. Если в
ARP-таблице уже есть запись,
соответствующая IP-адресу места
назначения, то из нее просто
берется Ethernet-адрес, и кадр,
содержащий IP-пакет, отправляется.
Если такой записи нет, то
посылается широковещательный
ARP-запрос. Узел с искомым IP-адресом
назначения принимает его и в
ARP-ответе сообщает свой Ethernet-адрес.
Эти действия соответствуют
обычному протоколу ARP, описанному
выше.

Протокол ARP с
представителем основан на том, что
шлюзы работают как представители
удаленных узлов. Предположим, в
подсети 128.6.5 имеется узел 128.6.5.2
(узел A на рис.12). Он желает послать
IP-пакет узлу 128.6.4.194, который
подключен к другой сети Ethernet (узел B
в подсети 128.6.4). Существует шлюз с
IP-адресом 128.6.5.1, соединяющий две
подсети (шлюз R).

Рис.12. Сеть, использующая протокол
ARP с представителем

Если в ARP-таблице узла A нет
маршрута доступа к узлу B, то узел A
посылает ARP-запрос узлу B.
Фактически машина A спрашивает:
"Если кто-нибудь знает Ethernet-адрес
узла 128.6.4.194, сообщите мне его".
Узел B не может ответить на запрос
самостоятельно. Он подключен к
другой сети Ethernet и никогда даже не
увидит этот ARP-запрос. Однако шлюз R
может работать от его имени. Шлюз R
отвечает: "Я здесь, IP-адресу
128.6.4.194 соответствует Ethernet-адрес
2:7:1:0:EB:CD", где 2:7:1:0:EB:CD в
действительности является
Ethernet-адресом шлюза. Это создает
иллюзию, что узел 128.6.4.194 подключен
непосредственно к той же локальной
сети Ethernet, что и узел A, и имеет
Ethernet-адрес 2:7:1:0:EB:CD. Когда узел A
захочет послать новый IP-пакет узлу
B, он использует указанный
Ethernet-адрес. Кадр, содержащий
IP-пакет, попадет к шлюзу R, а он
переправит его по назначению.

Заметим, что полученный
эффект такой же, как если бы в
таблице маршрутов была запись

сеть | флаг вида маршрутизации | шлюз | интерфейс
128.6.4.194 | косвенная | 128.6.5.1 | pe0

за исключением того, что
маршрутизация выполняется на
уровне модуля ARP, а не модуля IP.

Обычно рекомендуется
использовать таблицу маршрутов,
так как архитектура протоколов TCP/IP
предусматривает выполнение
маршрутизации на межсетевом
уровне. Однако иногда протокол ARP с
представителем очень полезен. Он
может помочь в следующих случаях:

  1. в IP-сети есть узел, который не
        умеет работать с подсетями;

    2.

  2. в IP-сети есть узел, который не
        может соответствующим образом
        реагировать на сообщения
        перенаправления;

    3.

  3. нежелательно выбирать
        какой-либо шлюз как маршрут по
        умолчанию;

    4.

  4. программное обеспечение не
        способно восстанавливаться
        при сбоях на маршрутах.

    5.

Иногда протокол ARP с
представителем выбирают из-за
удобства. Дело в том, что он
упрощает работу по начальной
установке таблицы маршрутов. Даже в
простейших IP-сетях требуется
устанавливать маршрут по
умолчанию, то есть использовать
команду типа "route add default ...", как
в ОС UNIX. При изменении IP-адреса
шлюза эту команду приходится
менять во всех узлах. Если же
использовать протокол ARP с
представителем, т.е. в команде
установки маршрута по умолчанию
указать метрику 0, то при замене
IP-адреса шлюза команду начальной
установки менять не придется, так
как протокол ARP с представителем не
требует явного задания IP-адресов
шлюзов. Любой шлюз может ответить
на ARP-запрос.

Для того, чтобы избавить
пользователей от обязательной
начальной установки маршрутов,
некоторые реализации TCP/IP
используют протокол ARP с
представителем по умолчанию в тех
случаях, когда не находят
подходящих записей в таблице
маршрутов.


Протокол TCP

Протокол TCP предоставляет транспортные услуги, отличающиеся от услуг UDP. Вместо ненадежной доставки датаграмм без установления соединений, он обеспечивает гарантированную доставку с установлением соединений в виде байтовых потоков.

Протокол TCP используется в тех случаях, когда требуется надежная доставка сообщений. Он освобождает прикладные процессы от необходимости использовать таймауты и повторные передачи для обеспечения надежности. Наиболее типичными прикладными процессами, использующими TCP, являются FTP (File Transfer Protocol - протокол передачи файлов) и TELNET. Кроме того, TCP используют система X-Window, rcp (remote copy - удаленное копирование) и другие "r-команды". Большие возможности TCP даются не бесплатно. Реализация TCP требует большой производительности процессора и большой пропускной способности сети. Внутренняя структура модуля TCP гораздо сложнее структуры модуля UDP.

Прикладные процессы взаимодействуют с модулем TCP через порты. Для отдельных приложений выделяются общеизвестные номера портов. Например, сервер TELNET использует порт номер 23. Клиент TELNET может получать услуги от сервера, если установит соединение с TCP-портом 23 на его машине.

Когда прикладной процесс начинает использовать TCP, то модуль TCP на машине клиента и модуль TCP на машине сервера начинают общаться. Эти два оконечных модуля TCP поддерживают информацию о состоянии соединения, называемого виртуальным каналом. Этот виртуальный канал потребляет ресурсы обоих оконечных модулей TCP. Канал является дуплексным; данные могут одновременно передаваться в обоих направлениях. Один прикладной процесс пишет данные в TCP-порт, они проходят по сети, и другой приклад ной процесс читает их из своего TCP-порта.

Протокол TCP разбивает поток байт на пакеты; он не сохраняет границ между записями. Например, если один прикладной процесс делает 5 записей в TCP-порт, то прикладной процесс на другом конце виртуального канала может выполнить 10 чтений для того, чтобы получить все данные. Но этот же процесс может получить все данные сразу, сделав только одну операцию чтения. Не существует зависимости между числом и размером записываемых сообщений с одной стороны и числом и размером считываемых сообщений с другой стороны.

Протокол TCP требует, чтобы все отправленные данные были подтверждены принявшей их стороной. Он использует таймауты и повторные передачи для обеспечения надежной доставки. Отправителю разрешается передавать некоторое количество данных, не дожидаясь подтверждения приема ранее отправленных данных. Таким образом, между отправленными и подтвержденными данными существует окно уже отправленных, но еще неподтвержденных данных. Количество байт, которые можно передавать без подтверждения, называется размером окна. Как правило, размер окна устанавливается в стартовых файлах сетевого программного обеспечения. Так как TCP-канал является дуплексным, то подтверждения для данных, идущих в одном направлении, могут передаваться вместе с данными, идущими в противоположном направлении. Приемники на обеих сторонах виртуального канала выполняют управление потоком передаваемых данных для того, чтобы не допускать переполнения буферов.


Протокол UDP

Протокол UDP (User Datagram Protocol - протокол пользовательских датаграмм) является одним из двух основных протоколов, расположенных непосредственно над IP. Он предоставляет прикладным процессам транспортные услуги, которые не многим отличаются от услуг, предоставляемых протоколом IP. Протокол UDP обеспечивает ненадежную доставку датаграмм и не поддерживает соединений из конца в конец. К заголовку IP-пакета он добавляет два поля, одно из которых, поле "порт", обеспечивает мультиплексирование информации между разными прикладными процессами, а другое поле - "контрольная сумма" - позволяет поддерживать целостность данных.

Примерами сетевых приложений, использующих UDP, являются NFS (Network File System - сетевая файловая система) и SNMP (Simple Network Management Protocol - простой протокол управления сетью).

Порты

Взаимодействие между прикладными процессами и модулем UDP осуществляется через UDP-порты. Порты нумеруются начиная с нуля. Прикладной процесс, предоставляющий некоторые услуги другим прикладным процессам (сервер), ожидает поступления сообщений в порт, специально выделенный для этих услуг. Сообщения должны содержать запросы на предоставление услуг. Они отправляются процессами-клиентами.

Например, сервер SNMP всегда ожидает поступлений сообщений в порт 161. Если клиент SNMP желает получить услугу, он посылает запрос в UDPпорт 161 на машину, где работает сервер. В каждом узле может быть только один сервер SNMP, так как существует только один UDP-порт 161. Данный номер порта является общеизвестным, то есть фиксированным номером, официально выделенным для услуг SNMP. Общеизвестные номера определяются стандартами Internet.

Данные, отправляемые прикладным процессом через модуль UDP, достигают места назначения как единое целое. Например, если процессотправитель производит 5 записей в UDP-порт, то процесс-получатель должен будет сделать 5 чтений. Размер каждого записанного сообщения будет совпадать с размером каждого прочитанного. Протокол UDP сохраняет границы сообщений, определяемые прикладным процессом. Он никогда не объединяет несколько сообщений в одно и не делит одно сообщение на части.

Контрольное суммирование

Когда модуль UDP получает датаграмму от модуля IP, он проверяет контрольную сумму, содержащуюся в ее заголовке. Если контрольная сумма равна нулю, то это означает, что отправитель датаграммы ее не подсчитывал, и, следовательно, ее нужно игнорировать. Если два модуля UDP взаимодействуют только через одну сеть Ethernet, то от контрольного суммирования можно отказаться, так как средства Ethernet обеспечивают достаточную степень надежности обнаружения ошибок передачи. Это снижает накладные расходы, связанные с работой UDP. Однако рекомендуется всегда выполнять контрольное суммирование, так как возможно в какой-то момент изменения в таблице маршрутов приведут к тому, что датаграммы будут посылаться через менее надежную среду.

Если контрольная сумма правильная (или равна нулю), то проверяется порт назначения, указанный в заголовке датаграммы. Если к этому порту подключен прикладной процесс, то прикладное сообщение, содержащееся в датаграмме, становится в очередь для прочтения. В остальных случаях датаграмма отбрасывается. Если датаграммы поступают быстрее, чем их успевает обрабатывать прикладной процесс, то при переполнении очереди сообщений поступающие датаграммы отбрасываются модулем UDP.